Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Consider putting more emphasis on readable git history; use squash strategy when merging single-unit PRs. #151
This is simply a suggestion from a user and contributor to this (excellent) Go project about a way I think it can be made better.
I was recently updating to the latest version and looking over the history to see what changed. On
In general, the git history of
It seems that most PRs here are made of commits that are just addressing internal PR feedback, rather than broken up into clean, logical and well documented separate commits to make the overall diff easier to understand. Yet they're merged via the "merge commit" strategy, which preserves individual PR commits with their original commit messages, resulting in the problem described above.
I suggest merging such PRs via the "squash merge" strategy, with a descriptive commit message that actually describes what changed on
For examples of what it can look like to have more readable git history, see:
Thanks for consideration!
Thanks for creating this @shurcooL -- I appreciate your attention to detail (especially since this more relates to how someone less involved in Vecty development might see / perceive Vecty).
Deciding the right strategy here is hard because sometimes changes / PRs do need to actually make two distinct changes from the perspective of the master branch. For example, if adding a new public function requires modifying an existing one. For these situations, what I will do from now on is write this detail into the squash merge commit message. I don't want to require contributors necessarily to create two distinct PRs in this case, since I wish to place more emphasis on code quality rather than git history.
But, to hopefully improve this issue as a whole, I've enabled GitHub's restrictions on merge/rebase commits, so that only squash merge is possible for me now:
We'll see if that helps improve our commit logicality overall. If it doesn't, we can try a different strategy :)
Closing for now.
Great, thanks a lot! I'm sure this will help significantly. Just make sure to review and edit the commit message title and body when merging PRs, so they contain only the information relevant to the final overall diff. You get a chance to easily modify them during the process of merging (this is one of the biggest benefits of this feature).
In those cases, which as you mention are more rare, you could use rebase merge strategy, but it requires each commit to have a clean commit message. It won't give you a chance to edit them when merging.