Proposal: make squash-merging the default behavior for gitlab MRs

[Johan Ouwerkerk]

On Sat, Oct 3, 2020 at 12:26 AM David Hurka <david.hurka at mailbox.org> wrote:
>
> > > However, it remains a fairly advanced workflow which is challenging for
> > > newcomers, drive-by-developers, and people not as familiar with git. For
> > > these people, squash-merging makes much more sense, [...]
>
> This workflow is too advanced for me. My commits are usually garbage like “fix
> pipeline”, and often contain notes on what I was doing and what I still need
> to do. If I was maintaining a clean history, that wouldn’t be possible.
>

Arguing from theory on maintaining a good commit history, this
actually means you should not be squashing your commits -- you should
be using the `fixup` operation in an interactive rebase....

But I understand where you are coming from. At work we used to have a
policy on squash commits for much the same reason, even professional
developers don't always bother to learn their scm tools. (I've also
worked with someone who did not appreciate the idea of commit history
and commit messages at all, as in a "why would I ever look at that?"
level of don't care).

Still others have raised a valid point that for long term maintenance
it is better to have a curated history if you can get it. That is why
we abandoned it eventually, especially for non-functional refactoring
commits or for a bunch of accumulated bug fixes squashing did more
harm than good. Essentially you get punished for doing things
'correctly' (for opinionated values of correct).

>
> Is it possible to make the default configurable for each user? Then I could
> simply check “Squash by default” and all my MRs are how I want them.
>
>

I'm not sure about that, but at least it *is* possible to do this per
repo, there's no need why projects should stick to a global default.
So if you're the maintainer you could nudge the default towards what
makes sense for your project and its dominant workflow. Go to Settings
(side bar) > General > Squashing and merging. Apparently that has been
a feature of Gitlab core since version 11.

Regards,

- Johan Ouwerkerk