I'm sorry, but making only "squash commits" is also a bad idea. You can have a MR with multiple independent, atomic, commits.
The "real" solution is making the developers aware of the issue and cleanup up their history before doing an MR.
The "real" solution is making the developers aware of the issue and cleanup up their history before doing an MR.
For a start, it's easy to review, and easier to disect if something breaks.
When messy git history is provided (i.e. a history of the developer fixing their own code that they missed), squashing can be a reasonable fallback. But it's never the best option, IMHO.
It's a separate project from git [0].
And the benefit is that instead of humans spending time deciding whether or not to squash commits in some branch before merging, or being asked to do so by a maintainer, a computer just does it automatically. It's a lot like automatic code formatting; it's a big win to have tools do things automatically, rather than requiring human time and judgement and communication.
They're not independent, they're related. Having multiple levels of "namespace" - repo -> PR -> commit - makes things easier to navigate, just like having multiple levels of folder in your filesystem.
> And the benefit is that instead of humans spending time deciding whether or not to squash commits in some branch before merging, or being asked to do so by a maintainer, a computer just does it automatically.
If you demand that each PR must be a single commit you just force the human to make that decision earlier and more manually.
> If you demand that each PR must be a single commit you just force the human to make that decision earlier and more manually.
How so? I think you may be misunderstanding the suggestion... The pattern is that people can have whatever commits they want on their own branch, but when that branch gets merged into the trunk, all those commits are automatically squashed into a single one. I don't see how that is "forc[ing] the human to make that decision earlier and more manually".
Right, so that means people have to decide whether something's going to be a separate commit immediately when they're working on it, and start a new branch if so. Or they could mess around splitting their branch into smaller branches at the end when they're ready to PR, but that's fiddlier than rebasing to split/merge commits.
I don't know what you mean by making PRs being "fiddler than rebasing to split/merge commits". What is the fiddliness you see?
That's a horrible way to work because when you squash a branch it breaks the history of any other branch that's based on it. So you'd have to do a fiddly rebase when you merge your first branch in.
> I don't know what you mean by making PRs being "fiddler than rebasing to split/merge commits". What is the fiddliness you see?
Imagine I've done a bunch of work in a branch, and then decide I want the contents of that branch to become three commits on master. With your workflow I have to split my branch into three branches, retroactively. That's fiddlier than just turning the commits on my branch into three commits.
It really isn't. Branches are just as cheap as commits. It's super easy to create three branches pointing at three arbitrary commits.