[stefan_]

So you have endless "Fix a" "Typo" "fixup" "revert redo" "add y missed in z" commits and then the squash pushes all that crap into the commit message for whatever the final mess will be?

Here is a random series from DRM patchwork: https://patchwork.kernel.org/project/dri-devel/list/?series=...

Would you squash that? Hell no, of course not. You would be mixing atomic changes in different subsystems. It breaks bisect and makes blames a mess.

Honestly, squash merges are frequently a sign of people who lack mastery in Git itself or make no effort to produce high-quality independent commits.

[oldtownroad]

A Pull Request should represent one change to the system (whether that’s a new feature or a bug fix). A commit to the Pull Request branch only has value in the context of the Pull Request. If you want a Pull Request to contain multiple atomic changes then sure, you need to do what you’re describing… but that’s entirely optional (and straying even further from the idea of changesets).

[avita1]

> So you have endless "Fix a" "Typo" "fixup" "revert redo" "add y missed in z" commits and then the squash pushes all that crap into the commit message for whatever the final mess will be?

In Github at least you can set the behavior to take the PR description by default as the squashed commit message. In fairness this is not the default. The default behavior for squash merges is to ask for a new commit message right as you hit the merge button, and the default is all of the messages from the commits being squashed together.

> make no effort to produce high-quality independent commits

I'm partial to sqaush merges when using github. I don't put much effort into the individual commit messages, instead I put lots of effort into the PR description (the thing reviewers will read, and what will eventually become the commit message in revision history). That said, one of my favorite features from gerrit at a past job was that the commit message itself could be reviewed.

[piotrkaminski]

> That said, one of my favorite features from gerrit at a past job was that the commit message itself could be reviewed.

Reviewable lets you review your commit messages just like any other file, BTW! (Disclosure: I'm the founder.)

[juped]

I see the problem as being that Github's bad git tooling blocks people from mastery in Git and actively discourages high-quality commits.

[falcojr]

> Honestly, squash merges are frequently a sign of people who lack mastery in Git itself or make no effort to produce high-quality independent commits.

So literally any open source project that accepts external contributions. For this reason we default to squash merge but will allow for exceptions if people ask for it and know how to structure their commits.

[da39a3ee]

> Honestly, squash merges are frequently a sign of people who lack mastery in Git itself or make no effort to produce high-quality independent commits.

Otherwise known as "colleagues" :)