7 ms·

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developer

by dkarl 3y ago

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. Git history should tell a simple, understandable story of each change. For example: 1) refactor existing code, 2) add feature. Or 1) add missing tests, 2) refactor existing code, 3) add feature. But since you're working on the fly with imperfect knowledge, it doesn't happen in such neat steps. Refactorings and behavior changes end up interleaved in your raw git history, so you need to do a little bit of cleanup by hand in order to present a simple story in the commit log. Of course if you have developers that don't do that and instead merge dozens of commits that just say wip, wip, wip, lol, fml, wip, wip, lol, yolo and you can't fire them or get them to change, then squash merges ftw.

bogeholm 3y ago
I ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. I prefer one commit to main per feature, a long with a good description on the GitHub PR. Sometimes I’ll branch out from a feature branch for the occasional and infamous ‘get CI working’ round of 10 one-line commits though, to not make it too muddy.
- ufo 3y ago
  Precisely, you want to keep it about one commit per feature. I think the parent comment was worried about monster merges that squash many features together.
- marcandre 3y ago
  The classic example where this fails is when needing to revert something. An atomic commit for the migrations + some atomic commits for the implementation mean you can easily revert the implementation, and leave the migration intact (as should be) and add a reverse migration.
- gwright 3y ago
  > why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. Several reasons: * facilitates much better code review discussions * enables use of git bisect to locate bugs * allows for informative commit messages associated with the changes * communicates clearly to future self about why changes were made
  - u801e 3y ago
    Another good reason is that having a small commit that changes just one thing is a lot easier to revert without encountering conflicts, even after other features have been committed to the main/master branch.
  - toast0 3y ago
    > * enables use of git bisect to locate bugs This is really only viable if each intermediate commit on a development branch is intended to be bug free. If that's the standard you and your team work with, that's fine, but it's not usually my standard; in a development branch, I may commit things that don't even compile, let alone work, if it's a good point to commit.
    - bonzini 3y ago
      The point of the parent comment is exactly that you should clean up the history before merging to a public branch, so that you can use bisect, even if so far you had wip wip doh wip as the commit messages. The way to get there is to have a mix of proper and wip commits.
      - WorldMaker 3y ago
        If merge points are your "known good" points anyway you can just use the powers of the git dag and `git bisect --first-parent` in your main branch to just bisect the merge points. There's no need for rebase/squash and you still get useful git bisect results.
        3y ago
- folmar 3y ago
  If things are heading towards a single commit an amend commit works fine for me. If I need a previous state I just get it from reflog.
- throw555chip 3y ago
  > why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. Agreed, it has been standard at most shops I've worked in the past 8-10 years.
- m000 3y ago
  > I ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. Squash-merge is a scourge. I've seen squash merged commits 30 lines long ("try 15", empty line, "try 14", empty line...). I'm not even sure if you can do anything about such commits because squash-merge is a github/gitlab thing. So, I'm not sure if there are hooks to block it via a commit message linter. And I've seen people going through some intense mental gymnastics to justify avoiding squashing locally, writing a proper commit message and then merging.
jimbob45 3y ago
I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. This is too much thought put into a VCS. I don’t want to have to think about my VCS at all beyond the commit message. For all of Git’s popularity, I’ve never seen benefits that justify the absurd amount of work and knowledge it takes to perform simple actions. It’s the VCS equivalent of Scheme or emacs.
- mablopoule 3y ago
  It's not about VCS, it's about code, both now and later, and context. If you need to do a workaround, or a complicated feature sometime it's nice to explain it as a comment in the code, but sometime it's better to put it as a comment inside the commit message. But if it's all merged i the end, along with lots of template changes, README changes, refactor irrelevant to the current changes, then you're losing an important way of navigating a codebase.
- dkarl 3y ago
  It really pays the effort back, though, when you can figure out why something was done, beyond knowing the feature it was related to, which is all you get with a squash merge.
  - mixmastamyk 3y ago
    Why not document it then? In a place where everyone can read it, instead of only developers.
    - Izkata 3y ago
      ...are you suggesting spending hours searching through documentation, hoping to possibly find something relevant, instead of just being able to run "git blame" to see why a specific line was changed?
      - mixmastamyk 3y ago
joshribakoff 3y ago
You can simply ask “git log” to show you one coarse entry per Pr rather than “destroying” the more granular history
- deleted 3y ago
  [deleted]
- erik_seaberg 3y ago
  This. It bugs me that people permanently throw away details of changes rather than show just the log of merge commits.
  - hhjinks 3y ago
    Why would I want to keep the details? Umpteen "tmp", "fix" and "fixed typo" provide negative value. When I check the blame of a line, I need to see the context of the change, meaning a description of all the work that was done as part of that change, and perhaps a ticket number. Anything else is noise that actively detracts from the value of the log. It's like 4K porn. It's less appealing when you see everything.
    - mablopoule 3y ago
      No yeah, absolutely do squash those commits, they are actually polluting the git history. The issue for me is when commit who are about adding a new value in the env file become mixed with template and responsive handling, mixed potentially with a bug fix.
jdhzzz 3y ago
That was me. Got fired. Kinda. I was laid off.
silenced_trope 3y ago
I disagreed with you up to this point: > Of course if you have developers that don't do that and instead merge dozens of commits that just say wip, wip, wip, lol, fml, wip, wip, lol, yolo and you can't fire them or get them to change, then squash merges ftw. Yes, any large organization has plenty of devs who all have their own style and preferences, for better or worse. Whoever demands they all bend to the one true way is a fascist (lol not really but you know). Just set up your CI/CD in such a way that PRs with weird git logs get squashed into one pretty message, preferably the PR description since other devs have to review the PR it's often given more effort. Set it up so that if things weren't formatted the "right way" they get auto-formatted or a test fails and the dev says "ah, I have to run that one task and then update the PR". I don't think a big organization is going to scale with developer "evangelists" demanding people write their commits a certain way either. conventionalcommits.org was the worst. I worked at one "big co" that tried to get devs to do this. Even after we had been doing it for a while, nobody ever went back to look at the history in such a way that it was worth it. We ended up throwing in the towel rather than the company trying to get all other teams to do it.
zaptheimpaler 3y ago
I get why you would prefer it clean but its just too much overhead for me. I naturally make lots of changes together - especially on a complex feature, you need to build things in a "full-stack" way horizontally so you can test as you go. Then pulling things apart into "clean" atomic commits later just takes too much time and I don't really know how to do it efficiently.
- yxhuvud 3y ago
  The thing is that when you get good at it the overhead will go down drastically. And the practice will make it easier and faster to extract small pull requests out of your main work that can be reviewed separately.
Rapzid 3y ago
There is a reason so many open source projects require squashing. Ain't nobody got time for that shit.
leptons 3y ago
It's like if someone said they wanted to invite you over for dinner. Then they started texting you. "at the grocery store". "bought a pound of beef". "bought some carrots". "Checking out now". "Arrived at home". "Turned oven on". "Turned oven to 450 degrees". "Turned oven up to 460 based on different recipe". "Starting to prep the beef now". and so on, and so on. I mean, just cook the damn dinner - I don't need to be needled about all the steps. I'll come over and bring the wine, and we'll eat a meal. I don't need to know every minor implementation detail in a commit log, to review and merge the branch. Arghhhh I have one dev on my team like this right now. I'll have to have a talk with them.
smcleod 3y ago
Eh, commit history is handy to have but if you spend all your time crafting the perfect commit messages and history you’ve likely lost sight of what matters. Great is the enemy of good and make the tools do the work for you. Commit as many WIPs or whatever then just hit squash and merge - it saves a lot of time and keeps momentum up.

by dkarl 3y ago

bogeholm 3y ago

I ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. I prefer one commit to main per feature, a long with a good description on the GitHub PR. Sometimes I’ll branch out from a feature branch for the occasional and infamous ‘get CI working’ round of 10 one-line commits though, to not make it too muddy.

ufo 3y ago
Precisely, you want to keep it about one commit per feature. I think the parent comment was worried about monster merges that squash many features together.
marcandre 3y ago
The classic example where this fails is when needing to revert something. An atomic commit for the migrations + some atomic commits for the implementation mean you can easily revert the implementation, and leave the migration intact (as should be) and add a reverse migration.
gwright 3y ago
> why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. Several reasons: * facilitates much better code review discussions * enables use of git bisect to locate bugs * allows for informative commit messages associated with the changes * communicates clearly to future self about why changes were made
- u801e 3y ago
  Another good reason is that having a small commit that changes just one thing is a lot easier to revert without encountering conflicts, even after other features have been committed to the main/master branch.
- toast0 3y ago
  > * enables use of git bisect to locate bugs This is really only viable if each intermediate commit on a development branch is intended to be bug free. If that's the standard you and your team work with, that's fine, but it's not usually my standard; in a development branch, I may commit things that don't even compile, let alone work, if it's a good point to commit.
  - bonzini 3y ago
    The point of the parent comment is exactly that you should clean up the history before merging to a public branch, so that you can use bisect, even if so far you had wip wip doh wip as the commit messages. The way to get there is to have a mix of proper and wip commits.
    - WorldMaker 3y ago
      If merge points are your "known good" points anyway you can just use the powers of the git dag and `git bisect --first-parent` in your main branch to just bisect the merge points. There's no need for rebase/squash and you still get useful git bisect results.
      - 3y ago
folmar 3y ago
If things are heading towards a single commit an amend commit works fine for me. If I need a previous state I just get it from reflog.
throw555chip 3y ago
> why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. Agreed, it has been standard at most shops I've worked in the past 8-10 years.
m000 3y ago
> I ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. Squash-merge is a scourge. I've seen squash merged commits 30 lines long ("try 15", empty line, "try 14", empty line...). I'm not even sure if you can do anything about such commits because squash-merge is a github/gitlab thing. So, I'm not sure if there are hooks to block it via a commit message linter. And I've seen people going through some intense mental gymnastics to justify avoiding squashing locally, writing a proper commit message and then merging.

jimbob45 3y ago

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. This is too much thought put into a VCS. I don’t want to have to think about my VCS at all beyond the commit message. For all of Git’s popularity, I’ve never seen benefits that justify the absurd amount of work and knowledge it takes to perform simple actions. It’s the VCS equivalent of Scheme or emacs.

mablopoule 3y ago
It's not about VCS, it's about code, both now and later, and context. If you need to do a workaround, or a complicated feature sometime it's nice to explain it as a comment in the code, but sometime it's better to put it as a comment inside the commit message. But if it's all merged i the end, along with lots of template changes, README changes, refactor irrelevant to the current changes, then you're losing an important way of navigating a codebase.
dkarl 3y ago
It really pays the effort back, though, when you can figure out why something was done, beyond knowing the feature it was related to, which is all you get with a squash merge.
- mixmastamyk 3y ago
  Why not document it then? In a place where everyone can read it, instead of only developers.
  - Izkata 3y ago
    ...are you suggesting spending hours searching through documentation, hoping to possibly find something relevant, instead of just being able to run "git blame" to see why a specific line was changed?
    - mixmastamyk 3y ago

joshribakoff 3y ago

You can simply ask “git log” to show you one coarse entry per Pr rather than “destroying” the more granular history

deleted 3y ago
[deleted]
erik_seaberg 3y ago
This. It bugs me that people permanently throw away details of changes rather than show just the log of merge commits.
- hhjinks 3y ago
  Why would I want to keep the details? Umpteen "tmp", "fix" and "fixed typo" provide negative value. When I check the blame of a line, I need to see the context of the change, meaning a description of all the work that was done as part of that change, and perhaps a ticket number. Anything else is noise that actively detracts from the value of the log. It's like 4K porn. It's less appealing when you see everything.
  - mablopoule 3y ago
    No yeah, absolutely do squash those commits, they are actually polluting the git history. The issue for me is when commit who are about adding a new value in the env file become mixed with template and responsive handling, mixed potentially with a bug fix.

jdhzzz 3y ago

That was me. Got fired. Kinda. I was laid off.

silenced_trope 3y ago

I disagreed with you up to this point: > Of course if you have developers that don't do that and instead merge dozens of commits that just say wip, wip, wip, lol, fml, wip, wip, lol, yolo and you can't fire them or get them to change, then squash merges ftw. Yes, any large organization has plenty of devs who all have their own style and preferences, for better or worse. Whoever demands they all bend to the one true way is a fascist (lol not really but you know). Just set up your CI/CD in such a way that PRs with weird git logs get squashed into one pretty message, preferably the PR description since other devs have to review the PR it's often given more effort. Set it up so that if things weren't formatted the "right way" they get auto-formatted or a test fails and the dev says "ah, I have to run that one task and then update the PR". I don't think a big organization is going to scale with developer "evangelists" demanding people write their commits a certain way either. conventionalcommits.org was the worst. I worked at one "big co" that tried to get devs to do this. Even after we had been doing it for a while, nobody ever went back to look at the history in such a way that it was worth it. We ended up throwing in the towel rather than the company trying to get all other teams to do it.

zaptheimpaler 3y ago

I get why you would prefer it clean but its just too much overhead for me. I naturally make lots of changes together - especially on a complex feature, you need to build things in a "full-stack" way horizontally so you can test as you go. Then pulling things apart into "clean" atomic commits later just takes too much time and I don't really know how to do it efficiently.

yxhuvud 3y ago
The thing is that when you get good at it the overhead will go down drastically. And the practice will make it easier and faster to extract small pull requests out of your main work that can be reviewed separately.

Rapzid 3y ago

There is a reason so many open source projects require squashing. Ain't nobody got time for that shit.

leptons 3y ago

It's like if someone said they wanted to invite you over for dinner. Then they started texting you. "at the grocery store". "bought a pound of beef". "bought some carrots". "Checking out now". "Arrived at home". "Turned oven on". "Turned oven to 450 degrees". "Turned oven up to 460 based on different recipe". "Starting to prep the beef now". and so on, and so on. I mean, just cook the damn dinner - I don't need to be needled about all the steps. I'll come over and bring the wine, and we'll eat a meal. I don't need to know every minor implementation detail in a commit log, to review and merge the branch. Arghhhh I have one dev on my team like this right now. I'll have to have a talk with them.

smcleod 3y ago

Eh, commit history is handy to have but if you spend all your time crafting the perfect commit messages and history you’ve likely lost sight of what matters. Great is the enemy of good and make the tools do the work for you. Commit as many WIPs or whatever then just hit squash and merge - it saves a lot of time and keeps momentum up.