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

[Francis Herne]

On Friday, 2 October 2020 18:39:37 BST 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.
> 
> 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.
> 
> Thoughts?
> 
> Nate
> 

I think this would be a mistake.

KDE projects are typically long-lived, with many contributors and
considerable turnover in those contributors over the years. Many of them are
also quite large.

Maintaining a clear history with good commit messages is crucial to keeping
our codebases maintainable. We already have many problems with legacy
components that no current maintainer really understands.

Small, logically-separated and labelled commits are a great help in many
situations, either bisecting to find recent bugs or when using `git blame` to
find out why some obscure line of code was added ten years ago.

We should consider "maintaining a sane commit history" as a fundamental skill
required of contributors -- of course, one that existing developers can help with.

Just as we wouldn't accept a change as-is that copy-pasted lots of code to add
some new feature, but give review feedback on how to generalize the original,
we shouldn't accept merges with 'tons of garbage commits' and instead explain
how to do things properly.

Squash-merging *hides* the problem of uncared-for commit messages,
by creating large and poorly-described commits that will cause technical debt
going forward.
It doesn't *solve* it, and it actively *discourages* the kind of merges
we should actually be encouraging.

My thoughts only, of course.

-Francis H