Possible to move some KF5 frameworks to invent?

[Ben Cooksley]

On Mon, Aug 12, 2019 at 6:24 PM Kevin Ottens <ervin at 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