[llvm-dev] Accidental Remote Branches Created on Github

Geoffrey Martin-Noble via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 8 09:39:44 PST 2021


This is one of the reasons everyone having write access is not a great
workflow. For my other projects I set the push URL for upstream to DISABLED
and then have a custom "sudo" git command
<https://gist.github.com/GMNGeoffrey/a1a2cc1baf811ce4ebcdeab6c24e8a2d> that
resets the URL. This doesn't work well with arc though, so I don't use it
for LLVM. If we switched to GItHub PRs, then everything could be forced to
go through a PR, but this requires additional automation (the only way for
someone to merge PRs is also for them to have write access).

On Sun, Nov 7, 2021 at 4:22 AM Mara Sophie Grosch via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> What about the action opening an issue for the bad branch and when that
> issue is 7 days old without someone closing it ("that branch is ok"),
> another (periodic) action then removes the branch?
>
> That would do the expected thing automatically, but with a visible delay
> to make it less dangerous. Also, the branches would only be lost on
> GitHub and still be available on the computer someone pushed them from -
> not perfectly safe, but better than "automatically lost forever".
>
> Of course only viable once issues are migrated to Github, otherwise it's
> chaos the people doing that migration surely wouldn't like ^^'
>
> Am Sat, Nov 06, 2021 at 09:46:46PM +0300 schrieb Anton Korobeynikov:
> >Unfortunately, GitHub does not allow this kind of "protection". Only
> >existing branches can be protected from pushes.
> >We already had such issues in the past when the outdated "master"
> >branch was pushed into the repo after the "master => main" transition.
> >We reported the issue to GitHub ~year ago, but this might be included
> >into their roadmap for 2023 or so.
> >
> >We've been told that the "workaround" is an action that removes all
> >non-known branches, however, I'm a little bit hesitant on having such
> >kind of powerful automation, that could remove something from the
> >repo.
> >
> >On Sat, Nov 6, 2021 at 3:56 AM Mara Sophie Grosch via llvm-dev
> ><llvm-dev at lists.llvm.org> wrote:
> >>
> >> This happening was actually a big fear for me when I got commit access,
> especially since I'm working on a fork for my hobby osdev project, not at
> all ready for upstreaming it - one wrong git push away
> >>
> >> Seeing this happening to other people is a bit of a relief
> >>
> >> Is it possible to configure GitHub to forbid that? Like everything
> except the normal branches being protected from pushes?
> >>
> >> Mara
> >>
> >> Am 6. November 2021 00:48:49 UTC schrieb Luke Benes via llvm-dev <
> llvm-dev at lists.llvm.org>:
> >> >A branch containing the D112590 patch was accidentally pushed to
> GitHub: https://github.com/llvm/llvm-project/tree/efb284c07e
> >> >
> >> >In the past couple of weeks, this also happened for
> >> >https://reviews.llvm.org/D107347
> >> >and
> >> >https://reviews.llvm.org/D108319
> >> >
> >> >This seems to be happening a lot recently. Is there a problem with the
> instructions to commit patches?
> >> >
> >> >_______________________________________________
> >> >LLVM Developers mailing list
> >> >llvm-dev at lists.llvm.org
> >> >https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >> --
> >> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> >
> >--
> >With best regards, Anton Korobeynikov
> >Department of Statistical Modelling, Saint Petersburg State University
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211108/2660978d/attachment.html>


More information about the llvm-dev mailing list