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

Re: Two Years of Squash Merge (2019)

#151

Post by rendaw » Sat, May 01, 2021, 10:59 AM UTC

sebastialonso wrote: post #39

calpaterson wrote: post #5

Earlier quoted context omitted.

> 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 think I'm missing something here. How valuable is to have 20 commits of "fix this error" , "fix the fix of the error", "revert all fixes", "real fix".... etc? I'd argue a PR with many commits such as these, conveys little no no useful information, when the actual change is 1-3 LOC. what about cleaning and filtering out useless commits, by soft reseting the branch and commiting just the actual changes to merge. Sure…

I've used these commits to identify the correct fix for bugs before. An early commit changed something to do X, but did it wrong. A "more fixes" commit tried to fix it but made it do Y.

It was obvious that the later commit was wrong and I could fix it to do X. If it were squashed I would have thought the original intent was to do Y and spent way more time trying to figure out how to fix it.

Obviously it's not guaranteed but throwing away that information is a bad idea if it's just for some arbitrary aesthetics. Same goes for rebasing to clean up the commit history, which would ostensibly do the same.

Re: Two Years of Squash Merge (2019)

#152

Post by Quekid5 » Sat, May 01, 2021, 11:24 AM UTC

codesnik wrote: post #77

gregmac wrote: post #53

Earlier quoted context omitted.

> A complete and utter waste of time. You spend more time messing about with rebase than solving problems. Unless you're using a garbage client (eg, the git CLI) a rebase to get rid of the "typo" "oops" type commits (when you forgot something) takes I'd say 10-20 seconds. Most commonly I do this when I have several changes on the go at once and forget to commit a fixed unit test, new import, or something like that. I…

git CLI isn't so bad for that, why? I do --fixup commits all the time, git commit -i gives me all the power to reorder, merge and even split commits.

While the typical basic rebase isn't so bad from the CLI, something like magit is faster, and much much faster for anything apart from the basic rebases.

Re: Two Years of Squash Merge (2019)

#153

Post by beberlei » Sat, May 01, 2021, 11:52 AM UTC

waffletower wrote: post #57

rubyist5eva wrote: post #56

Earlier quoted context omitted.

How is it unwieldy? They don't even show up locally when you `git branch` unless you've checked them out. Otherwise they just sit there doing nothing, there is literally no maintenance required on them once they've been squashed into mainline. Most central repositories end up having hundreds (or even thousands) of "finished" branches that nobody ever looks at anyway.

Depends on configuration if you wind up having that many. I use `git branch -v` often to figure out what branch a colleague is working on. I guess I could apply my same logic and use filtering tools here as well. But I don't see the benefit of squashing the merge commits when git CLI, github etc. can give you the same view without the gratuitous data loss.

They show Github in their screenshots, and on Github you can delete a branch and the original commit history in the UI is still kept and available. So you don't have the branches locally, but Github still has them around.

Re: Two Years of Squash Merge (2019)

#154

Post by lmilcin » Sat, May 01, 2021, 12:09 PM UTC

My biggest issue with squashing everything is that every non-trivial development necessarily composes of three types of changes:

- functional changes (changes functionality as visible from outside),

- refactorings (changes how application works internally)

- reformatting (does not change the compiled paths but improves readability).

Now, there is very good case for keeping these types of changes separate.

For example, when I want to change something I may want to first refactor it (to bring the code to a state where the functional change can be done easier and is more clearly correct), then I will make separate commit/commits to modify the code functionally, then I will possibly follow with more changes to "clean up" -- refactor the code using my newly acquired knowledge.

I always mark refactorings / reformat by starting the commit message with the word 'refactoring' or 'reformatting' so that any reviewer can easily see that these commit are not allowed any functional changes (and if I made one it means I made a mistake).

What this means is that the functional changes are as light and to the point as possible, not burdened with unrelated changes. It makes it much easier to review and ensure they are correct when I "tell" the reviewer which parts of the change are intended to modify functionality and which are just housekeeping.

That information obviously vanishes if you squash everything together.

**

Another big problem with squashing commits is that they become very large.

I find it makes much more sense to compose a large change from smaller, simple, logical, understandable changes that each produces (hopefully) working application.

If you find a problem with the commit (for example as a result of bisecting to find where something was introduced) it is much easier to understand what the change intended and compare this with the actual code modification to figure out where I failed.

Obviously, when you squash it the information is gone.

Re: Two Years of Squash Merge (2019)

#155

Post by bassdropvroom » Sat, May 01, 2021, 12:11 PM UTC

I've never understood the need for squash merging. One of the biggest advantage this article mentions is that the history will look neater. Well what if I told you that you can have both? Git log has the `--merges` flag (I could be mistaken on the flag name), which will remove everything that's not a merge (it does require using `--no-ff` which github et al use when merging PRs). Now you have a clean commit history that doesn't include the individual commits as if it was squashed. But your real history still contains the individual commits thus doing something like bisect will give you much small commits to look at.

Granted, I'm not aware of github or the like having a view that only shows merges but git log command definitely does.

Re: Two Years of Squash Merge (2019)

#156

Post by piotrkaminski » Sat, May 01, 2021, 12:43 PM UTC

jcelerier wrote: post #15

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…

> 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. gerrit has solved this issue for years by showing the diffs between each successive revision of a patch. e.g. look here the files at different origin patchsets : https://codereview.qt-project.org/c/qt/qtwayland/+/321246/3....

And as it happens, Reviewable also deals with this perfectly fine. In fact, it appears that most any code review tool save GitHub is perfectly all right with amend/force-push...

Re: Two Years of Squash Merge (2019)

#157

Post by asimpletune » Sat, May 01, 2021, 2:19 PM UTC

gouggoug wrote: post #98

asimpletune wrote: post #32

Earlier quoted context omitted.

Hey, so this POV comes up a lot, and I have to say that I think it mistakes how git commits should work, but I’ll add that you can sort of have both. First, in a production branch, git commits should be thought of as functions. Like “Apply commit X, get feature Y, unapply it and you get the reverse”. So the problem with preserving full git history in master is that it breaks that invariant. You have to sort of do lik…

> First, in a production branch, git commits should be thought of as functions. Like “Apply commit X, get feature Y, unapply it and you get the reverse”. So the problem with preserving full git history in master is that it breaks that invariant. You have to sort of do like a range of commits, but then that doesn’t really always work because often times other commits can be interleaved into yours. Merge commits allow…

No I understand, I’m just saying in the real world that’s not how projects are maintained.

Re: Two Years of Squash Merge (2019)

#158

Post by vikingcaffiene » Sat, May 01, 2021, 2:35 PM UTC

tharkun__ wrote: post #111

waffletower wrote: post #7

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

I would argue that you only loose irrelevant information and you gain the ability to rollback. Without squashing, you are actually way worse off for a "10 times a day release regimen". We release every hour and we squash and rebase with a straight master history. This enables us to almost mechanically just roll back to the previous commit that was out on Prod, should something happen and it's very easy to skip (rever…

> Each ticket is one commit. If you revert one commit, you are guaranteed to have a working piece of software and you won't have a potentially not even compiling intermediate commit that was subsequently fixed up during a PR, which can happen without squashing.

This is the key point and I liked it so much that I bookmarked it. Hope you don’t mind. :)

I frequently have to debate with my teammates on the value of squash merging into our mainline branches. Another value add that squash merge brings is that it enables what I call “accidental documentation”. You get a easy to parse log of work that was done and a link right to the PR with a description and any discussion around it. As a lead I frequently need to coordinate teammates and communicate technical decisions. It’s invaluable to be able to just pull up the commit log and go right to the work in question without having to wade through a bunch of noise.

It also helps a ton with writing release notes.

Re: Two Years of Squash Merge (2019)

#159

Post by nojvek » Sat, May 01, 2021, 2:48 PM UTC

I love squash merge. I’ve seen it being enforced in many places I’ve worked at.

You’d think losing commit history due to squash is a bad thing, but it’s actually a good thing in a large team. When you have 100s of merged into master you want to see one atomic commit per PR. If something is wrong, then you can revert that individual commit.

It’s also much better signal:noise ratio. Most individual commits in PRs are like “fix”, “ugh! lint” and things like that. The PR title has much better names. GitHub squash merge adds title and link to pull request with the number. So if you want to see finer version of squash commit, you can always do that.

However squash merges tell you one big then in the main/master branch “who did what when”. Git bisects to find when a regression was introduced work work well. The whole idea is a merged PR is a piece of work ready to be deployable. Individual PR commits are not.

Re: Two Years of Squash Merge (2019)

#160

Post by welearnednothng » Sat, May 01, 2021, 3:08 PM UTC

This is one of the things I miss about Perforce - every merge was effectively a squash merge, but the branch was still there, just not visible by default (if I remember correctly). It was the best of both worlds - you keep a complete audit trail, but it was out of the way and didn’t interfere with your day to day view of the commit log. Moreover, there was never any discussion on merge strategies as there was just the one way to do it.

On top of that, they had some amazing tools for aiding in audits when you needed them.

I’m not suggesting we all switch to Perforce! But I do miss that aspect of it.