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
