Two Years of Squash Merge (2019) • Hacker News Board

Re: Two Years of Squash Merge (2019)

#41

Post by hinkley » Fri, Apr 30, 2021, 7:40 PM UTC

gouggoug wrote: post #2

I 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…

Squash merge is for people who are so wedded to the idea that you should guess why the code is the way that it is instead of looking it up, that they want to make sure nobody else can do it either.

You know, assholes.

It’s fine if you don’t want to use something, or use it, as long as it doesn’t drag your whole team into your decision. Which squash merge does.

Re: Two Years of Squash Merge (2019)

#42

Post by maxioatic » Fri, Apr 30, 2021, 7:42 PM UTC

leafmeal wrote: post #26

scott0129 wrote: post #9

Earlier quoted context omitted.

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 rev…

Fixup commits are a good way to work around this. https://git-scm.com/docs/git-commit#Documentation/git-commit... You still create your "clean up" commits, but it's done in a way where git can automatically squash everything back together in the end. See also https://git-scm.com/docs/git-rebase#Documentation/git-rebase...

Huh, never knew about this. Seems quite useful. Thanks!

Re: Two Years of Squash Merge (2019)

#43

Post by [deleted] » Fri, Apr 30, 2021, 7:42 PM UTC

gouggoug wrote: post #2

I 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…

[deleted]

Re: Two Years of Squash Merge (2019)

#44

Post by drtz » Fri, Apr 30, 2021, 7:44 PM UTC

gouggoug wrote: post #2

I 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…

> 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.

The article makes an argument that each commit should be "a single logical change." Squashing thousands of lines of code from a long-running feature branches into a single commit is obviously not what the author is suggesting.

Re: Two Years of Squash Merge (2019)

#45

Post by [deleted] » Fri, Apr 30, 2021, 7:44 PM UTC

cortesoft wrote: post #34

gouggoug wrote: post #2

I 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…

> 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. So, the only way that I can think that having the squash commit broken into individual commits would help to find the one broken line is because it would enable git bisect to find the failing commit. However,…

[deleted]

Re: Two Years of Squash Merge (2019)

#46

Post by waffletower » Fri, Apr 30, 2021, 7:45 PM UTC

rubyist5eva wrote: post #12

eximius wrote: post #8

Earlier quoted context omitted.

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.

In the article he says he keeps the original branch with all of the history around after they squash them with a reference to the original PR in the squashed merge commit message. So you can always just checkout the original branch and go digging in the full history.

Unwieldy to keep branches around even on moderate sized teams/projects. You don't need them to have a `squashed` view of history when needed. I am surprised that developers still cling to this outdated squashing regimen when pull request tools found on github, gitlab, bitbucket etc. already provide synthetic squash views derived from atomic commits by default.

Re: Two Years of Squash Merge (2019)

#47

Post by sjoruk » Fri, Apr 30, 2021, 7:50 PM UTC

finnh wrote: post #30

ginja wrote: post #10

Earlier quoted context omitted.

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)

Spot-on for both counts. Preserving a PR's individual commits in the master branch is insane - many of those commits won't represent a fully working system anyway, so why keep them in master?

> many of those commits won't represent a fully working system anyway

This is entirely within the control of the developer(s) working on the project. Whether it's worth it is up to the people working on it. It's certainly not insane though - it's much easier to fix merge/rebase conflicts when each commit is small and easy to reason about.

Re: Two Years of Squash Merge (2019)

#48

Post by thom » Fri, Apr 30, 2021, 7:50 PM UTC

calpaterson wrote: post #5

gouggoug wrote: post #2

I 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 seeme…

Do people here have examples of some bugs for which they had to resort to VCS history to find the cause? I'm struggling to picture a single bug in my whole career where this would have been quicker than just following the logic of the code. If there's information in commit messages that isn't evident in the code itself, that seems a terrible way to live.

Re: Two Years of Squash Merge (2019)

#49

Post by Rapzid » Fri, Apr 30, 2021, 7:50 PM UTC

calpaterson wrote: post #5

gouggoug wrote: post #2

I 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 seeme…

I agree with you in part, depending on the project, if that means just squashing it down first. This at least can keep the integration branch somewhat sane and without a bunch of intermediate commits that are junk and won't build.

For this reason I prefer people to rebase on the integration branch instead of merging it in to stay current; unless there is a reason not to. And a lot of open source projects require PRs that to be pre-squashed or be able to be squashed before merging!

However, there is a time and place still for deliberately crafting the PR commits. For instance if you are wanting the reviewer to be able to review chunks of the PR in isolation/stages, or if you want each of the commits to be buildable.. I suppose also for review/testing.

This all depends on the project and other factors like the wider org.

Re: Two Years of Squash Merge (2019)

#50

Post by Cymen » Fri, Apr 30, 2021, 7:50 PM UTC

gouggoug wrote: post #2

I 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 am in agreement however I suspect many developers have never seen the usage of "git bisect" to track down a bug and fix it. Once you see the power of that, I think one can come to appreciate more the granular git history that is present when not using squash commits.

Of course, git bisect still works with squash commits it just makes your job as the bug fixer much harder because typically squashed commits are quite large so you have to figure out what in the N lines of code introduced the defect.