Challenge 2 - Create a Game

[AlexHedley]

No description provided.

[KubaO]

There should be no merge commit in the PR. That also suggests that you're using merge commits instead of rebasing in your workflow. This produces very noisy commit histories. At the moment, this PR looks as follows in git:

The "create a game" commit should be based directly on main.

All that merge history shouldn't be there. I suggest that you:

0. fetch from upstream
1. check out main
2. create a new temporary branch, say c2again, based on main, and check it out
3. cherry-pick and commit the relevant change from c2
4. check out c2 again
5. force-reset to c2again
6. push c2 to github

[AlexHedley]

It's the sync fork button in the GitHub UI that's adding it.

[AlexHedley]

Could squash commits on merge be an option?

[KubaO]

It's the sync fork button in the GitHub UI that's adding it.

Don't use that button. Instead, ensure that your changes are always rebased to main.

Could squash commits on merge be an option?

There shouldn't be any merging to begin with. Changes should be based on main and not on anything else. Then this won't be a problem.

[WaynePhillipsEA]

I just want to step in briefly here to add a bit of perspective.

I completely understand the preference for a clean linear Git history, and it’s fair to aim for that where we reasonably can. At the same time, I do want to strike a balance - especially for documentation contributions, so that we don’t end up discouraging valuable community members over workflow details that are easy to trip over (particularly when GitHub’s own UI flow doesn't help)

Alex’s intent here was clearly to help improve the docs, and the extra commits are an understandable side-effect of the “Sync fork” flow rather than carelessness. We can absolutely document a preferred workflow going forward (e.g. rebase or fresh branches / cherry-pick).

At this early stage, contributions matter more than perfection, and we can usually fix history more easily than we can replace motivated contributors.

Thanks to everyone involved for the work and the care you’re putting into the docs.

[KubaO]

I am always up for cleaning things up and committing myself, but I realize that this skews the contribution statistics that github keeps. A big concern of mine is making sure that contributors are credited appropriately.

I think I will do as follows: For contributions that need git history cleanups but are otherwise OK, I'll commit them myself. For contributions that don't need git history cleanups but need some other cleanups, I'll indicate that in the review and expect an update.

Edit: I just realized that even if the PRs are not credited, the individual commits will definitely get credited, as their authorship is retained. So I'll just go ahead and do what needs doing to get things moving. Thank you Wayne and Alex.

[KubaO]

Live now.