Could we use sysadmin/repo-metadata to know which branch is stable and therefore should be protected and trigger the hooks for closing bugs, etc?
On Mon, Aug 12, 2019, 17:39 Ben Cooksley <bcooks...@kde.org> wrote: > On Mon, Aug 12, 2019 at 6:24 PM Kevin Ottens <er...@kde.org> wrote: > > > > Hello, > > Hi Kevin, > > > > > On Sunday, 11 August 2019 22:14:19 CEST Albert Astals Cid wrote: > > > With phabricator you can do a "force push" to your review[1], with > gitlab > > > you can not[2]. > > > [...] > > > [2] without having your own fork of a repository, that is annoying for > > > various reasons > > > > I'm genuinely surprised about that claim. Are we sure that it's not a > setting > > on our instance forcing this? I'm currently working on a project where > you can > > force push in non-protected branches without your own fork. > > Our hooks prevent force pushes from taking place within our mainline > repositories. > > This is done for a couple of reasons. > > The first, that in order for us to reliably operate things like > closing of bugs on Bugzilla and sending emails and IRC Notifications, > it is necessary for the hooks to be able to detect when a commit is > "new" and therefore needs to be processed for this sort of action. > Unfortunately due to how Git works, there is no difference between a > genuinely new commit, and one that has simply been rebased - they're > both "new" as far as the hooks are concerned. This means we cannot > allow rebasing within any branch which is subject to notification or > other hook processing. > > The second, is that recovering your work when someone has > rebased/force pushed the branch underneath you, is something which is > non-trivial unless you are familiar with the process. Even for those > who are experienced, it is possible to make mistakes in the process of > doing so, and either lose commits or mangle the metadata associated > with the commit (such as the authorship information - an incident > which happened earlier this year). At the time KDE migrated to Git it > was decided on a community wide basis that familiarity with this isn't > something we should expect casual contributors to have. > > Those familiar to Git will be aware that it is very much possible to > limit the scope of hooks like our Notification hooks, while still > allowing them to be caught when entering branches that are subject to > Notification. At this time the only proposals i've seen for this have > been for "everything but master and stable branches" which > unfortunately is not a scalable solution we can support due to the > significant variance in schemes used for naming stable branches across > different projects (not without pushing the maintenance role for > handling all these different naming schemes on to Sysadmin) > > > > > Regards. > > -- > > Kevin Ottens, http://ervin.ipsquad.net > > > > enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en > > Regards, > Ben >
