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

[Konstantin Kharlamov]

On Fri, 2020-10-02 at 11:39 -0600, Nate Graham wrote:
> Hello folks,
> I've been told that our Sysadmins have developed some tooling capable of
> checking the "Squash when merging" checkbox by default for new Merge
> Requests. This would be a downstream solution to
> https://gitlab.com/gitlab-org/gitlab/-/issues/222175.
>
> I'd like to propose that this be done as a sane default for new Merge
> Requests. Now, personally I have gotten used to the alternative "curate
> your MR's git history" approach and have written documentation for it at
>
https://community.kde.org/Infrastructure/GitLab#Curating_your_merge_request_commit_history
.
>
> 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, and when they forget
> to check that checkbox and someone merges their work, the result is tons
> of garbage commits in the git history.

Well, what you say makes sense. But I don't think squashing commits would help
too much with having clean git history in these cases. You see, when there's an
MR with tons garbage commits, this likely also means the contributor is doing
something complicated enough that should be separated to more than one commit.
In
which case it's easy to see a problem with this squash-checkbox: a maintainer
asks the author to broke their MR to three commits per functional changed,
contributors does that, and then everyone happily forget to remove that pesky
"squash-checkbox", so upon merging all the work in separating commits gets
wasted.

It may be a question of whether that newcomer needs to learn to work with git
just to contribute. Well, I think that the fact they try to contribute means
they're a developer, whether a beginner or not. And as a developer, they have to
learn to work with the git-history. I think it's a nice moment to mention this
great blog-post on the matter by Peter Hutterer, a libinput maintainer:
http://who-t.blogspot.com/2009/12/on-commit-messages.html It may be old, but
still relevant.


> Accordingly, I think squash-merging makes sense as the default value to
> avoid this. People who are comfortable with the "curated MR commit
> history" workflow will of course still be able to turn it off. IMO it
> makes more sense to ask experts to turn it off than to ask newcomers and
> novices to turn it on.

Please don't. This will result in having many MRs with a valid history to get
squashed just because people would keep forgetting to uncheck it. Given there
are
much more people who aware of how to work with git history, I think this would
hurt more than occasionally merging a non-squashed MR from a newcomer.