On Tue, Oct 15, 2019 at 8:12 PM Ben Cooksley <bcooks...@kde.org> wrote: > > On Wed, 16 Oct 2019, 05:17 Johan Ouwerkerk, <jm.ouwerk...@gmail.com> wrote: >> [...] > > > It was complexity of that degree that I was primarily concerned about when > people started pushing for being able to force push and use a rebase workflow. > > For a first time contributor or anyone who isn't familiar with working with > Git rebase, that sort of workflow is incredibly daunting, downright scary and > is likely to push them in the direction of simply not contributing at all. > > As I'm sure we can all agree, that isn't something we want at all - we want > it to be easy and straight forward to get involved for everyone. > > In cases such as the one you have above, I think a simple merge commit would > be completely fine in that instance, especially given it is an uncommon event.
It was like this on Phabricator until now so we should leave it like that for the GitLab transition. That being said the git merge workflow instead of rebase has certain advantages and just because we did it until now with rebase does not need to imply we have to continue to do so for all time. What I mean by that: if you set the default of GitLab merge behavior to rebase, please do it in a way that allows individual projects to override the default at some point in the future if seen fit.
