Re: dist-git force push

2022-04-03 Thread Michal Schorm
On Fri, Apr 1, 2022 at 12:52 PM Michael J Gruber wrote: > In particular, this would allow to avoid the many "commit missing patch", > "actually commit the change", > "duh" commits which happen after a successful `fedpkg build --scratch --srpm` > followed by a half-(how do you say this nicely)ed

Re: dist-git force push

2022-04-02 Thread Matthew Miller
On Fri, Apr 01, 2022 at 06:22:47PM +0200, Hans de Goede wrote: > 1. If you have plenty of bandwidth + enough CPU + RAM: > > fedpkg mockbuild && fedpkg commit -sc && fedpkg push && fedpkg build > > 2. Or if you don't: > > fedpkg commit -sc && fedpkg scratch-build --arches=x86_64 --srpm && fedpkg

Re: dist-git force push

2022-04-01 Thread Kevin Fenzi
On Fri, Apr 01, 2022 at 06:22:47PM +0200, Hans de Goede wrote: > Hi, ...snip... I don't think we should ever allow force pushes in dist git repos. Even aside detecting if something has been built, you basically screw up the repo for everyone else who has work in progress against it. > 2. Or if

Re: dist-git force push

2022-04-01 Thread Paul Howarth
On Fri, 1 Apr 2022 18:22:47 +0200 Hans de Goede wrote: > On 4/1/22 18:09, Ondrej Mosnacek wrote: > >> Context switches for maintainers are expensive! And while I don't > >> personally think the "oops fixup" commits are a problem, a "PR > >> with CI" workflow doesn't get rid of them by any means.

Re: dist-git force push

2022-04-01 Thread Michael J Gruber
> On Fri, Apr 1, 2022 at 4:27 PM Robbie Harwood wrote: > > Why not this then: > > - fedpkg commit -sc && fedpkg scratch-build --srpm && fedpkg push > && > fedpkg build > > Yes, it'll still take longer, but you won't need to context switch > unless the scratch build fails (which would make you

Re: dist-git force push

2022-04-01 Thread Hans de Goede
Hi, On 4/1/22 18:09, Ondrej Mosnacek wrote: > On Fri, Apr 1, 2022 at 4:27 PM Robbie Harwood wrote: >> Kamil Dudka writes: >> >>> On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote: >>> - check whether the "new object name" is descendant of (contains) "old build object

Re: dist-git force push

2022-04-01 Thread Ondrej Mosnacek
On Fri, Apr 1, 2022 at 4:27 PM Robbie Harwood wrote: > Kamil Dudka writes: > > > On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote: > > > >> - check whether the "new object name" is descendant of > >> (contains) "old build object name" (rather than "old object name", which > >>

Re: dist-git force push

2022-04-01 Thread Kamil Dudka
On Friday, April 1, 2022 4:26:36 PM CEST Robbie Harwood wrote: > Kamil Dudka writes: > > On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote: > >> - check whether the "new object name" is descendant of > >> (contains) "old build object name" (rather than "old object name", which > >>

Re: dist-git force push

2022-04-01 Thread Robbie Harwood
Kamil Dudka writes: > On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote: > >> - check whether the "new object name" is descendant of >> (contains) "old build object name" (rather than "old object name", which >> would forbid any force push) >> This would allow to rewrite a branch

Re: dist-git force push

2022-04-01 Thread Kamil Dudka
On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote: > Hi there > > I know why we do not allow to force push to dist-git in the rpms namespace, You can easily do force pushes in your own fork. Rewriting the authoritative branches in the official repositories is problematic for too

dist-git force push

2022-04-01 Thread Michael J Gruber
Hi there I know why we do not allow to force push to dist-git in the rpms namespace, but I am wondering whether we can implement this more in line with the reason: dist-git has to be a permanent record for the "source" (spec etc.) against which a package is built, but currently we deny pushing