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

Re: Two Years of Squash Merge (2019)

#21

Post by qudat » Fri, Apr 30, 2021, 7:29 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…

Agreed but I also think this depends heavily on context. If the organization cares a lot of clean commit messages, have a nice git history, and want PRs to be submitted in a clean state, great!

This is not always the case. I've worked on codebases where we rarely scan the git history messages for anything useful, it's just as easy for us to dig into the code to figure out what's wrong.

Re: Two Years of Squash Merge (2019)

#22

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

I file this one under: It Depends™

If your software development process requires that multiple people have a hand in each pull request, or these pull requests are part of a more complex merge graph, then I can clearly see the argument for NOT doing squash merge. This is plainly obvious to me and I would be on your side for not going down the squash path. Knowing who was responsible for each part is a very important thing.

If your software development process only ever has a single author per pull request, and these are only ever directed from work branch->master branch, then I would strongly argue for doing the squash merge option. This is what we do today, because we find it to be the ideal blend of hiding subjective commit styles while still preserving essential knowledge about who did what.

Occasionally, we will break our own rules (oops i didn't squash that one), but we don't make a big deal out of it. There are way more important things to worry about most of the time. There is only ever 1 specific commit hash you build your software at, so it doesn't really matter if the branch has 1 or 10,000 commits in it.

Re: Two Years of Squash Merge (2019)

#23

Post by dyeje » Fri, Apr 30, 2021, 7:31 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…

It's a prime example of engineers mistaking aesthetics for utility.

Re: Two Years of Squash Merge (2019)

#24

Post by jakeva » Fri, Apr 30, 2021, 7:32 PM UTC

decebalus1 wrote: post #4

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

> figuring out where to put the bike shed.

Anyway, the _real_ question is what color to paint the bike shed?

Re: Two Years of Squash Merge (2019)

#25

Post by tablespoon » Fri, Apr 30, 2021, 7:32 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…

> A complete and utter waste of time. You spend more time messing about with rebase than solving problems.

Eh. Not really. A clean history is a good resource for figuring out what was changed and why. Cleaning up history isn't even that much work anyway.

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

Only if the commit messages are shitty, which unfortunately they often are. I try to summarize what I'm changing and what I indent those changes to accomplish, because if there's one thing I hate doing, it's spending more time than necessary to puzzle out what I (or a coworker) was thinking at the time.

VCS history can be a pretty powerful tool, but a messy history discourages the use of it.

Re: Two Years of Squash Merge (2019)

#26

Post by leafmeal » Fri, Apr 30, 2021, 7:33 PM UTC

scott0129 wrote: post #9

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

Re: Two Years of Squash Merge (2019)

#27

Post by throwaway1777 » Fri, Apr 30, 2021, 7:34 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…

Strongly disagree. Mainline branch commit history should be clean atomic commits that you can roll back. Otherwise you are just asking for trouble on any merge conflict or hotfix scenario.

Re: Two Years of Squash Merge (2019)

#28

Post by jtchang » Fri, Apr 30, 2021, 7:34 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 has the major disadvantage of getting rid of valuable meaningful git history.

There are reasons against it but the real world is messy. Developers tend to commit things, recommit, undo, redo, move things around. Is this valuable history? It can be but I would say 99% of the time it's more valuable to have a good commit message about what was intended rather than what actually happened.

The idea of squash merge is to make the history clean from the get-go as you said.

Re: Two Years of Squash Merge (2019)

#29

Post by bonzini » Fri, Apr 30, 2021, 7:35 PM UTC

nickbauman wrote: post #14

Generally, time spent twiddling with the repo is time not spent delivering code. It's a distraction. Yes git has all these features that lets you do that and those feature matter when you're committing to the Linux repo which has thousands of eyes and your commit history has to help you communicate to a very wide audience. But the vast majority of us are not using git like this. I've used git bisect so rarely all thi…

Time spent twiddling with the repo is time saved in the future debugging or writing documentation.

You can have large refactoring PRs for which splitting them further really makes little sense(*), but that have a huge risk of introducing regressions. Being able to bisect them is much easier with a properly maintained repository.

(*) And then you spend time twiddling with GitHub, which is the same as twiddling with the repo except with worse tools.

Re: Two Years of Squash Merge (2019)

#30

Post by finnh » Fri, Apr 30, 2021, 7:35 PM UTC

ginja wrote: post #10

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