24 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

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
      I use blame often to blame. Code tells how, not why—the domain of specs and comments. Commit messages effectively don’t exist for non-developers. I put spec links in doc strings whenever possible. They are accessible to everyone—devs, PMs, SMEs, stakeholders that pay bills, and myself when at a web browser. Searching is not required but even if it was it would be a tiny fraction of “hours.”
- scme0 3y ago
  But if you're using pull requests, you can just look up the PR to get the reasoning and details of the squash commit. I would argue that if you need it to be separate commits after merging, you should create separate PRs most of the time.
Dylan16807 3y ago
> I don’t want to have to think about my VCS at all beyond the commit message. Fine as an opinion. > 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. This is just wrong. When people talk about this, it's not about git at all. You write some code, and you make it into commits. Part of that is choosing if/how to organize it with multiple commits, and how much effort you want to put into that. This is fundamental to using a VCS, any VCS. Or by analogy, if a lot of emacs users complain about your spelling, that's not because emacs is overly demanding.

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
    I use blame often to blame. Code tells how, not why—the domain of specs and comments. Commit messages effectively don’t exist for non-developers. I put spec links in doc strings whenever possible. They are accessible to everyone—devs, PMs, SMEs, stakeholders that pay bills, and myself when at a web browser. Searching is not required but even if it was it would be a tiny fraction of “hours.”
scme0 3y ago
But if you're using pull requests, you can just look up the PR to get the reasoning and details of the squash commit. I would argue that if you need it to be separate commits after merging, you should create separate PRs most of the time.

Dylan16807 3y ago

> I don’t want to have to think about my VCS at all beyond the commit message. Fine as an opinion. > 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. This is just wrong. When people talk about this, it's not about git at all. You write some code, and you make it into commits. Part of that is choosing if/how to organize it with multiple commits, and how much effort you want to put into that. This is fundamental to using a VCS, any VCS. Or by analogy, if a lot of emacs users complain about your spelling, that's not because emacs is overly demanding.