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

[Elvis Angelaccio]

On 02/10/20 19:39, Nate Graham wrote:
> Hello folks,

Hi

> 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.

People should not blindly merge a MR without checking the commit history
first:
- if the submitter pushed one or more well-written atomic commits, those
can be merged without squashing
- otherwise, whoever merges the MR should squash the history and write a
proper commit message. Or they should ask the submitter to fix its history.

> 
> 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.

+0, I don't have a preference for this default value. As explained, it's
orthogonal to the problem of a bad commit history.

> 
> Thoughts?
> 
> Nate

Cheers,
Elvis