Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git: Please Stop Squash Merging

lucasoshiro.github.io

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Git: Please Stop Squash Merging

#21

Post by lucasoshiro »

yawaramin wrote: post #9

This post is full of weird non sequiturs and logical fallacies. So what if git doesn't have a single command to 'squash-merge'? It doesn't natively support a 'pull request' workflow either. Code forges build convenience functionality on top of git. If I didn't have the 'squash merge' feature I'd just use an interactive rebase to fixup/squash the branch's commits before doing a fast-forward-only merge, because I don't…

> I don't want my repo history littered with meaningless noise like these merge commit messages > I also don't want a commit history that looks like London's tube system map.

Both sentences starts with "I don't want" followed by aesthetic choices.

Re: Git: Please Stop Squash Merging

#22

Post by munksbeer »

matheust wrote: post #17
munksbeer wrote: post #13

Earlier quoted context omitted.

Thank you, but no. I enjoy working on a branch and committing small changes at a time, sometimes trivial, sometimes not even compiling, sometimes formatting or whatever the hell I feel like. When it comes time to review, I squash all those trivial changes manually (rebase -i) and present a clean branch for review. We could try harder to enforce stricter policies on devs to ensure they're much more disciplined about t…

> Thank you, but no. I enjoy working on a branch and committing small changes at a time, sometimes trivial, sometimes not even compiling, sometimes formatting or whatever the hell I feel like. When it comes time to review, I squash all those trivial changes I understand the workflow you've described here. I think the key word is "trivial". Otherwise, when I squash together many "large" patches, the end result will be…

> Otherwise, when I squash together many "large" patches, the end result will be a huge commit with possibly unrelated changes

Of course not, that would be silly, but who is doing that? I suppose some silly outfits have long lived branches onto which they throw lots of stuff then finally go back to master, but that isn't what this article is arguing about. If I address PR comments, such as typos, simplifying logic etc, this is just noise that doesn't need to be in any history, except maybe for a deep dive by looking at the PR itself.

Yet the article seems to be arguing otherwise and suggesting we use tooling to solve a problem that we don't even have. As someone else said, it is such an engineering nitpick "you're using it wrong" type of article.

We enforce squash commits when we mere PRs to master, and we never have any issues with it.

Re: Git: Please Stop Squash Merging

#23

Post by munksbeer »

MartijnHols wrote: post #14
munksbeer wrote: post #13

Earlier quoted context omitted.

Thank you, but no. I enjoy working on a branch and committing small changes at a time, sometimes trivial, sometimes not even compiling, sometimes formatting or whatever the hell I feel like. When it comes time to review, I squash all those trivial changes manually (rebase -i) and present a clean branch for review. We could try harder to enforce stricter policies on devs to ensure they're much more disciplined about t…

Interactive rebasing away fixups in your branch is not squash merging. I agree that fixing a typo in a variable or a small linting issue in a previous (recent or not-pushed) commit in your branch is usually good. A carefully crafted commit history is all anyone can ask for. But then squashing away that history once the PR is merged would be a waste of a good history and the effort you put into it. If you end up squas…

I can't follow what you're saying. Once people start reviewing the PR, we typically do not manually squash (rebase -i) because it is helpful to see how the flow of the review went. Following this, we sometimes end up with 10 commits on a PR that are just addressing various comments, nitpicky or not.

Then once approved, we click the "squash and merge" button, and github squashes all that useless noise into a single commit on master for us.

We don't have any complaints about this workflow.

Re: Git: Please Stop Squash Merging

#24

Post by lucasoshiro »

munksbeer wrote: post #22
matheust wrote: post #17

Earlier quoted context omitted.

> Thank you, but no. I enjoy working on a branch and committing small changes at a time, sometimes trivial, sometimes not even compiling, sometimes formatting or whatever the hell I feel like. When it comes time to review, I squash all those trivial changes I understand the workflow you've described here. I think the key word is "trivial". Otherwise, when I squash together many "large" patches, the end result will be…

> Otherwise, when I squash together many "large" patches, the end result will be a huge commit with possibly unrelated changes Of course not, that would be silly, but who is doing that? I suppose some silly outfits have long lived branches onto which they throw lots of stuff then finally go back to master, but that isn't what this article is arguing about. If I address PR comments, such as typos, simplifying logic et…

> If I address PR comments, such as typos, simplifying logic etc, this is just noise that doesn't need to be in any history, except maybe for a deep dive by looking at the PR itself.

Read the rewriting tools references in the text.

> Yet the article seems to be arguing otherwise and suggesting we use tooling to solve a problem that we don't even have.

Read again about the debugging tools mentioned. I never saw a code that needed some kind of debugging. Keeping the history clean makes the debug easier.

You could also say the same about tests. Tests don't solve any problem as long as the code works. But if it doesn't work, test will help to quickly find out where it is broken.

Otherwise, you have no benefit of squashing. If you don't see the benefits of having a commit history, you can use Google Drive instead.

> We enforce squash commits when we mere PRs to master, and we never have any issues with it.

Just because you never had doesn't mean that they don't exist. If you saw it at least once, it means that it exists. I saw it once, and I related here: https://lucasoshiro.github.io/posts-en/2024-06-27-squash-sub...

Re: Git: Please Stop Squash Merging

#25

Post by lucasoshiro »

munksbeer wrote: post #23
MartijnHols wrote: post #14

Earlier quoted context omitted.

Interactive rebasing away fixups in your branch is not squash merging. I agree that fixing a typo in a variable or a small linting issue in a previous (recent or not-pushed) commit in your branch is usually good. A carefully crafted commit history is all anyone can ask for. But then squashing away that history once the PR is merged would be a waste of a good history and the effort you put into it. If you end up squas…

I can't follow what you're saying. Once people start reviewing the PR, we typically do not manually squash (rebase -i) because it is helpful to see how the flow of the review went. Following this, we sometimes end up with 10 commits on a PR that are just addressing various comments, nitpicky or not. Then once approved, we click the "squash and merge" button, and github squashes all that useless noise into a single co…

> Then once approved, we click the "squash and merge" button, and github squashes all that useless noise into a single commit on master for us.

This is not what squash is. I suggest you to read again the section "What squash merge actually is". tl;dr: "Squash merge is the same as the true merge but with a missing information: the reference to the merged branch."

> We don't have any complaints about this workflow.

Repeating the same answer: Just because you never had doesn't mean that they don't exist. If you saw it at least once, it means that it exists. I saw it once, and I related here: https://lucasoshiro.github.io/posts-en/2024-06-27-squash-sub...

Re: Git: Please Stop Squash Merging

#26

Post by lucasoshiro »

fargle wrote: post #11
yawaramin wrote: post #9

This post is full of weird non sequiturs and logical fallacies. So what if git doesn't have a single command to 'squash-merge'? It doesn't natively support a 'pull request' workflow either. Code forges build convenience functionality on top of git. If I didn't have the 'squash merge' feature I'd just use an interactive rebase to fixup/squash the branch's commits before doing a fast-forward-only merge, because I don't…

upvoting! "I also don't want a commit history that looks like London's tube system map" i don't care how you do it. squashing? git reset followed by sensible commits? intense ninja-like git commit hygiene? or my favorite , liberal amounts of git rebase -i? the only things i care about are these: 1. your PR contains a series of atomic commits 2. each commit makes a single logical change. 3. that each logical change is…

> London's tube system map

Perhaps you live in London, a city with many subway lines and stations that makes many places easy to reach, just like a repository with commits that makes it easy to find where something was introduced.

I live in São Paulo, a city 2 times bigger than London but with a smaller subway map. Few places have a subway station near them. Finding the nearest station is only part of the problem, as we need to find a way to go from the station to where we need to be. Just like a repository that uses squash merges.

Re: Git: Please Stop Squash Merging

#27

Post by yawaramin »

lucasoshiro wrote: post #26
fargle wrote: post #11

Earlier quoted context omitted.

upvoting! "I also don't want a commit history that looks like London's tube system map" i don't care how you do it. squashing? git reset followed by sensible commits? intense ninja-like git commit hygiene? or my favorite , liberal amounts of git rebase -i? the only things i care about are these: 1. your PR contains a series of atomic commits 2. each commit makes a single logical change. 3. that each logical change is…

> London's tube system map Perhaps you live in London, a city with many subway lines and stations that makes many places easy to reach, just like a repository with commits that makes it easy to find where something was introduced. I live in São Paulo, a city 2 times bigger than London but with a smaller subway map. Few places have a subway station near them. Finding the nearest station is only part of the problem, as…

Lol! This is the first time I've seen squash merging be compared to lack of public transit infrastructure :-D

Re: Git: Please Stop Squash Merging

#28

Post by strawhatguy »

lucasoshiro wrote: post #19
strawhatguy wrote: post #6

My bad experience with squash merging was with Stash at my last job. Some developers there thought the "clean history" was so worth it they made squash-merging the default merge strategy. The result: the git repository (at least in Stash) slowed to a crawl, because the comments to the commits were several hundred MiB. It was nuts. Never seen a git hosting site go that slow before. Actually had to replace the whole re…

> the comments to the commits were several hundred MiB I did't even thought about it. In fact, those are hundreds of lines that no one would read, as the commits are lost and you can't do anything with them...

Totally, but that's what was there. For background, I think the comment created would be a combination of all the comments in all the commits in that branch. Horrid.

I hadn't even heard of squash commits before this, and we looked into it because the Stash site kept timing out. All the people that had built it was just shrug, Stash sucks, always been this way, like all seniors-that-are-actually-juniors-because-big-corp-can't-keep-good-folks-to-teach-them do. I mean maybe the tool sucks, but at least give it a fair chance first.

Re: Git: Please Stop Squash Merging

#29

Post by strawhatguy »

yawaramin wrote: post #8
strawhatguy wrote: post #6

My bad experience with squash merging was with Stash at my last job. Some developers there thought the "clean history" was so worth it they made squash-merging the default merge strategy. The result: the git repository (at least in Stash) slowed to a crawl, because the comments to the commits were several hundred MiB. It was nuts. Never seen a git hosting site go that slow before. Actually had to replace the whole re…

Sounds like the problem was not squash merging, but the slow and buggy implementation of Stash (hilariously bad naming for a git-related product btw).

Yeah, it was Atlassian's git thing, or one they bought, and combined it with bitbucket or something.

I'll say it was with the configuration and the buggy implementation of squash merging button with Stash.

After replacing the repo, people were amazed with how fast it was. Also apparently I became notorious as the committer of the whole repository, since first commit was mine!

Re: Git: Please Stop Squash Merging

#30

Post by strawhatguy »

lucasoshiro wrote: post #20
yawaramin wrote: post #8

Earlier quoted context omitted.

Sounds like the problem was not squash merging, but the slow and buggy implementation of Stash (hilariously bad naming for a git-related product btw).

> hilariously bad naming for a git-related product btw) I only understood what "Stash" is in this situation after your comment. Looks like it is an Atlassian product that was renamed: https://confluence.atlassian.com/bitbucketserver/bitbucket-r... Funny that they don't mention the name collision as reason for renaming it...

I think Atlassian built their own, and bought the other. And now it's bitbucket. Maybe nothing left of Stash anymore. Maybe that's a good thing.
Post reply on HN