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

[David Hurka]

> That doesn't prevent me from having a clean history when I finally git-push
> to an opened MR, so my colleagues could easily review my code. I know that
> if I'd push some "dirty" commits to my "merge request", my colleagues would
> unnecessarily spend time navigating these commits, and reviewing code-lines
> that were fixed in the further commit. And why? Just because I didn't care
> to squash last commit?

Why should colleagues navigate through any commits, when the MR is intended to 
be squashed? Wouldn’t squash merge make it easier to review an MR?

> I should note though that while I do a lot of stuff with git as I work
> (e.g. swapping commits, amending a commit, going back to a commit in history
> then changing it, etc.), I spend minuscule amount of time on it.

I think this can not be expected from new contributors.

If the default for this checkbox is configurable per user, I would like it 
when new MRs from new contributors are squash merged by default.

New users usually submit easier patches, right? Such patches usually can not 
be separated into individual, clean commits, unless we want to push broken 
code to production branches.

If we reject a patch submitted a new user with “Thanks, your patch finally 
fixes this annoying bug, but we can not accept it, because I don’t like your 
git history. Please learn git first.”, that would IMHO be the first step to 
make KDE a closed community.