On Mon, Oct 14, 2019 at 1:42 PM Aleix Pol <aleix...@kde.org> wrote: > > On Sun, Oct 13, 2019 at 10:57 PM Albert Astals Cid <aa...@kde.org> wrote: > > > > I find the merge behavior to be not what we've been doing in phabricator so > > given the idea is to maintain our workflows i'd appreciate if we can agree > > on continue doing the same. > > > > https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html > > +1 > > This is the enterprise version though, does this apply to the community?
All of their docs are under the /ee/ path on docs.gitlab.com - for the most part they're fully applicable to CE though. Features that are EE only are marked with the corresponding EE versions (see https://docs.gitlab.com/ee/user/project/insights/ for instance) > > Adding sysadmin as CC, since they're the ones who will have to put it > to work in the end. We received a request for this a little while ago - please see https://phabricator.kde.org/T11190 While we did investigate this, as it turns out this is part of Gitlab that is non-customisable in terms of the default (regardless of your edition). What we will likely end up doing is changing all projects to that setting via the Gitlab API following the rollout of Gitlab to all projects and ensure we change that configuration for new projects as part of the project provisioning process. Please note that our current Gitlab setup should be considered to be an evaluation system, hence why we haven't looked into implementing this yet. In terms of this request though: 1) Work branches will eliminate most of the problems and pain you're experiencing here I suspect 2) Forcing rebases to land changes means that you will be unable to land changes that comprise more than 100 commits, as may be the case with larger bodies of work. In terms of why (2) happens, this is because our commit hooks, in order to prevent abuse/flooding of common spaces (such as #commits on Freenode, and the kde-comm...@kde.org mailing list) block attempts to push greater than 100 commits. From the perspective of the commit hooks, rebased commits are entirely new commits - and any commit coming from a work branch (once those are introduced) will also count as a new commit. Our hooks do operate on merges performed by Gitlab and will result in Gitlab returning 'Something went wrong' when you try to merge in changes greater than 100 commits as the hooks will block Gitlab from performing the (rebased) merge for you. In these cases, should we proceed down the path of not creating merge commits (and requiring rebases in the event of it being a non-fast forward) then projects will need to perform the merge manually in these instances, or ask Sysadmin to temporarily switch them back to the Gitlab default of creating merge commits in order to land that series of changes. > > Aleix Cheers, Ben
