[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Proposal: make squash-merging the default behavior for gitlab MRs
From: Nate Graham <nate () kde ! org>
Date: 2020-10-06 14:26:02
Message-ID: 05a98b56-8d37-78a0-fb4f-0255e8a6e5dc () kde ! org
[Download RAW message or body]
Taking stock of the responses so far, it doesn't seem like there's much
enthusiasm for the original proposal. That's fine, and I can understand
the desire to push people to improve their git skills. It seems like
there is some agreement on an alternative, which various people have
proposed:
On 10/3/20 6:10 AM, David Edmundson wrote:
> 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.
On 10/5/20 8:21 AM, Volker Krause wrote:
> Even better might be to force an explicit decision by not having a
default for
> this at all, e.g. by offering "Rebase" and "Squash + Rebase" actions
next to
> each other.
On 10/5/20 10:38 AM, Ömer Fadıl USTA wrote:
> my suggestion is not making squash default but implement a way that
> will pops up a question if there are more then 1 commits in mr so user
> can select on that time.
GitLab already *kind of* offers this, in the form of the "Squash
commits" checkbox next to the merge button. Apparently it's not obvious
enough though, because I can think of a bunch of cases of multi-commit
MRs with mostly garbage commits accidentally not being squashed when
merging.
Maybe this is just a teething issue that we'll overcome with more
experience?
Nate
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic