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

Two Years of Squash Merge (2019)

blog.dnsimple.com

Post reply on HN
Print view View original

61–70 of 194 posts

Re: Two Years of Squash Merge (2019)

#61

Post by chmaynard »

Here's an alternative that appears to accomplish the same thing:

  # checkout feature branch
  git switch feature

  # reset HEAD while preserving changes to working tree
  # commits on feature branch will become orphans
  git reset --soft main

  # commit all changes on feature branch
  git add -A; git commit -m 

  # checkout the main branch and merge
  git switch main
  git merge feature

Re: Two Years of Squash Merge (2019)

#62

Post by finnh »

sjoruk wrote: post #47
finnh wrote: post #30

Earlier quoted context omitted.

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.

> it's much easier to fix merge/rebase conflicts when each commit is small and easy to reason about.

I agree, but I'd say it in the context of PRs. It's much easier to fix issues (and avoid them) when _PRs_ are small & easy to reason about.

Re: Two Years of Squash Merge (2019)

#63

Post by bennysomething »

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…

Disagree, having a bunch of commits made up of undo, redo , dunno what I'm doing , oh no now I know, commits is pretty annoying. Squash solves that (for me, when dealing with other peoples merges). Obviously just my opinion etc

Re: Two Years of Squash Merge (2019)

#64

Post by FalconSensei »

I love squash-merge, and never had to see which specific commit inside a PR/MR changed a line. In my current project we use `JIRA-### Title` and the MR title (Gitlab). All information is in the ticket. Also, IF I needed to see the detailed commit history for that merge, Gitlab still has it. We try to have our ticket to be small, so any merge shouldn't have a long commit history anyway.

Re: Two Years of Squash Merge (2019)

#65

Post by gouggoug »

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…

- Generally time spent writing documentation is time not spent delivering code.

- Generally time spent commenting code is time not spent delivering code.

- Generally time spent diagramming on a white board is time not spent delivering code.

- Generally time spent writing specs is time not spent delivering code.

Yet, doing all of these are actually extremely important. How much importance you give each one of them is up to you that's for sure.

So, "Generally, time spent twiddling with the repo is time not spent delivering code", is true, it's nonetheless important, and, this statement disregards the fact that "twiddling" usually only takes a few minutes.

Re: Two Years of Squash Merge (2019)

#66

Post by marton78 »

bennysomething wrote: post #63
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…

Disagree, having a bunch of commits made up of undo, redo , dunno what I'm doing , oh no now I know, commits is pretty annoying. Squash solves that (for me, when dealing with other peoples merges). Obviously just my opinion etc

The problem is real and the parent commenter addresses it: learn interactive rebasing to craft a beautiful commit history.

Re: Two Years of Squash Merge (2019)

#67

Post by allenu »

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.

Yep, I agree. In my ideal world, everybody (including me) would have pristine commits that are broken up logically. There wouldn't be small commits created as part of code review to fix things up based on feedback. You'd just have a single "Add feature X" or "Fix bug Y".

However, it's an imperfect world and there are trade-offs. It's hard to train people to do things the right way, and then policing when they do it the wrong way or putting roadblocks in place to make them do it the right way takes energy, and often the benefit is minor. It really depends on how frequently you pore through your history to find an offending bug and a whole bunch of other team policy that isn't directly related to git commits.

I used to spend a lot of energy rebasing so that I could have a beautiful history, but honestly it hasn't benefited me that much. I still rebase, but I'm not so strict about it on my commits, nor others. I'd rather spend my focus and energy elsewhere.

Just do what the team is comfortable with and be flexible.

Re: Two Years of Squash Merge (2019)

#68

Post by streblo »

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.

The only way I've ever seen this accomplished is through Github squash and merge.

Re: Two Years of Squash Merge (2019)

#69

Post by sethherr »

gregmac wrote: post #53
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…

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

> I'll also note that in code that is well-commented and well-tested, this step is rarely necessary.

This is the most important line from this comment.

If I'm using blame or bisect, it means I did something wrong.

I merge 10 times a day - and if it takes me a minute, because I'm slower than you - that means it's ten minutes a day. Add the cognitive load of the whole process and the added time of explaining it to other team members - 10 minutes is an underestimate.

I'm going to spend that time writing tests and comments, since even you note that they're the better option.

Squash is good enough. I spend my energy improving the right things.

Re: Two Years of Squash Merge (2019)

#70

Post by PaulDavisThe1st »

edoceo wrote: post #6
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…

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.

hah, a big merge. in the next month or so, i will need to merge a branch with nearly 500 commits that change more that 15k lines of code, under development for more than a year.

but yeah, like your "one big merge", i do not intend to squash it (though there are actually some arguments in favor that only kick on with a merge of this size).

Post reply on HN