On Thu, Oct 17, 2019 at 4:24 PM Roman Gilg <subd...@gmail.com> wrote: > > 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. >
The rebase behaviour described by Johan is something you would need to do manually with feature branches, while the Gitlab behaviour in question in this thread is a fully automated one. That makes it quite different from what we had with Phabricator. (Side note: Phabricator doesn't carry commits, so anything landed is always squashed) > 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. As noted previously, Gitlab does not allow setting a default for new projects - so what we will do is change the setting on all of our projects, and ensure we change it on all new projects going forward. I'm not sure whether we should support/permit projects to opt to a different workflow, as it is bound to cause someone to notice it is different and then file a Sysadmin ticket saying it's wrong because it is different to the policy applied to all other projects. This means that we (Sysadmin) then have to track who has opted to have different behaviour, and people are then bound to challenge why it is different when we close those tickets as invalid. Regards, Ben
