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