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

[David Edmundson]

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

I do agree that state is a problem. Because we know that box exists we
press approve when the commits themselves are garbage and then we get this
mess.

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

-1
New to kde doesn't mean new to git. We have a lot of skilled people, and
one of the biggest gains of adopting gitlab is that we expose git more
directly.

Imho that feature request to gitlab to set a default isn't actually what
we're after. It's requesting a bodge that replaces one problem with another.

We don't want a default for a merge option, we want an exposed action like
the existing rebase button to squash things within the local branch. That
would mean reviewers can review commits (and therefore review commit
messages properly) and you still provide an easy path for people who can't
squash locally. If we only approve when commits themselves are sound, it'll
be easy to manage. Win-win.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20201003/2f3bb93b/attachment.htm>