Two Years of Squash Merge (2019)
blog.dnsimple.com
Two Years of Squash Merge (2019)
1–10 of 194 posts
Re: Two Years of Squash Merge (2019)
#2I will always fight tooth and nail against squash merge.
Squash merge has the major disadvantage of getting rid of valuable meaningful git history.
Squash merge is not the proper solution for keeping your git history clean, it is a hack using the side effect of squash.
Keeping your git history clean is a matter of policy, best-practices and education:
Developers should be required to submit _clean_ PRs, that is, PR's whose git history has been organized and refactored in such a way that it removed "clean up commits", "typo fix", etc.
When you squash merge a feature branch that has thousands of lines of code, and 6 months later you have a bug introduced by this feature branch, it becomes extremely hard to find which line introduced the bug.
On the other hand, if you kept the history, and if this history was clean from the get go, it becomes easy to read the commits one-by-one and understand the issue.
Don't use squash+merge.
edit: I see numerous comment saying, in essence, "squash+merge" is what gets rid of the dirty history. No, developers must learn the existence of `git rebase --interactive`, which is the command to use to clean your git history[0]. "squash" is one possible action, among others, that helps cleaning the history.
[0]: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
Re: Two Years of Squash Merge (2019)
#3This is great! The takeaway for me is that with squash merge you get one commit with all the changes which (optimally) has the full context in the commit message.
My typical workflow is basically the same, but with putting all that context in the merge commit. This allows you to find it with a bit of work (blame to find the commit line, then figure out where that was merged in, then find the merge commit). Squash merge puts all that context in one commit, and keeps a linear history. I had assumed squash merge squashes the commits, then creates a merge commit still, which would mean you'd probably do something like combining messages for each commit in the squash commit message, then capturing the overview in merge commit.
The article says you can still find the individual commits via PR, which is a minor disadvantage as it means you can only do exploration of these via github. If you've deleted the topic branch on github are they still accessible? If it's been garbage collected by git (or never existed locally if you're looking at someone else's changes), is there a way to check them out?
Re: Two Years of Squash Merge (2019)
#4The older I get the more I find these discussion as counterproductive as figuring out where to put the bike shed.
I worked in teams that did squash merge and in teams that didn't. And in teams where some did and some didn't, on the same repo. In the grand scheme of things it didn't matter, except for hardliners who had nothing better to talk about.
Re: Two Years of Squash Merge (2019)
#5I will always fight tooth and nail against squash merge. Squash merge has the major disadvantage of getting rid of valuable meaningful git history. Squash merge is not the proper solution for keeping your git history clean, it is a hack using the side effect of squash. Keeping your git history clean is a matter of policy, best-practices and education: Developers should be required to submit _clean_ PRs, that is, PR's…
> Developers should be required to submit _clean_ PRs, that is, PR's whose git history has been organized and refactored in such a way that it removed "clean up commits", "typo fix", etc.
A complete and utter waste of time. You spend more time messing about with rebase than solving problems.
When you're digging through VCS history due to a bug you often ignore the commit message anyway - if the code did what it seemed to do you wouldn't be there.
Re: Two Years of Squash Merge (2019)
#6I will always fight tooth and nail against squash merge. Squash merge has the major disadvantage of getting rid of valuable meaningful git history. Squash merge is not the proper solution for keeping your git history clean, it is a hack using the side effect of squash. Keeping your git history clean is a matter of policy, best-practices and education: Developers should be required to submit _clean_ PRs, that is, PR's…
maybe its not 100% one way or the other?
I love squash for somethings, but not others
today I brought in one big merge, 20+ commits , so don't squash it.
but I also have 20 "little fix" branches, with 1,2 commits each which I merge all together and squash in as one merge to main.
Re: Two Years of Squash Merge (2019)
#7Many developers naively sell `git squash` using a clarity argument. By squashing you lose historical information: there are times when the content of a merge requires a paper trail, times when individual commits can aid to separate the portions of a merge you would like to keep versus those you would like to rollback. Perhaps in a 10 times a day release regimen you decide never to look for such history. One size does not fit all, however.
I prefer a "have your cake and eat it too" approach. Keep the commit history. Use readily available tools to squash when performing analysis should you choose:
`git log -p --first-parent` (git 2.31+ ability available in early versions of git with different syntax)
Re: Two Years of Squash Merge (2019)
#8I will always fight tooth and nail against squash merge. Squash merge has the major disadvantage of getting rid of valuable meaningful git history. Squash merge is not the proper solution for keeping your git history clean, it is a hack using the side effect of squash. Keeping your git history clean is a matter of policy, best-practices and education: Developers should be required to submit _clean_ PRs, that is, PR's…
If only there was a way to have our cake and eat it too.
I'm assuming there is because I'm assuming those squashed commits are floating somewhere in the reflog and somehow connected to the squashed commits in a way that should still let you bisect if only we had a tool to make it not suck.
Alas, maybe someone with greater git-fu can inform us.
Re: Two Years of Squash Merge (2019)
#9I will always fight tooth and nail against squash merge. Squash merge has the major disadvantage of getting rid of valuable meaningful git history. Squash merge is not the proper solution for keeping your git history clean, it is a hack using the side effect of squash. Keeping your git history clean is a matter of policy, best-practices and education: Developers should be required to submit _clean_ PRs, that is, PR's…
I would agree with your points if not for the fact that "clean up commits" or "typo fix" is a necessary result of PR's.
Your teammate will request changes in your code, and the only way to cleanly communicate "yes I made that change, and ONLY that change" is through these clean-up commits.
Otherwise, if you amend/force-push or open an entirely new PR, 99% of the diff are things that your team has already seen and reviewed.
Squash merges let you clearly communicate how you addressed PR comments, while also keeping the master history clean.
Re: Two Years of Squash Merge (2019)
#10I will always fight tooth and nail against squash merge. Squash merge has the major disadvantage of getting rid of valuable meaningful git history. Squash merge is not the proper solution for keeping your git history clean, it is a hack using the side effect of squash. Keeping your git history clean is a matter of policy, best-practices and education: Developers should be required to submit _clean_ PRs, that is, PR's…
I do agree that PRs should have a clean history. However:
- Services like GitHub allow you to restore the original branch, so you never actually lose history. So I don't see any major drawbacks of squashing on merge.
- If your PRs are several thousand lines long, they probably should've been broken up into multiple PRs (your reviewer will appreciate it)