Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* Re: Please enable fast forward for user branches
       [not found] <1af95023-580d-6774-c307-1a38bf3dc073@suse.cz>
@ 2021-03-30  4:09 ` Joel Brobecker
  2021-03-30  5:36   ` Mike Frysinger via Gdb-patches
  0 siblings, 1 reply; 5+ messages in thread
From: Joel Brobecker @ 2021-03-30  4:09 UTC (permalink / raw)
  To: Martin Liška; +Cc: Binutils, gdb-patches

Hello,

> I would like to sync up my binutils user branches to the primary server.
> However, I can't do rebases which makes it not usable at all:
> 
> $ git push origin me/startswith -f
> Enumerating objects: 257, done.
> Counting objects: 100% (257/257), done.
> Delta compression using up to 16 threads
> Compressing objects: 100% (140/140), done.
> Writing objects: 100% (140/140), 22.31 KiB | 951.00 KiB/s, done.
> Total 140 (delta 134), reused 0 (delta 0), pack-reused 0
> remote: Resolving deltas: 100% (134/134), completed with 117 local objects.
> remote: error: denying non-fast-forward refs/heads/users/marxin/startswith (you should pull first)
> To ssh://sourceware.org/git/binutils-gdb.git
>  ! [remote rejected]         me/startswith -> users/marxin/startswith (non-fast-forward)
> error: failed to push some refs to 'ssh://sourceware.org/git/binutils-gdb.git'

I think the error above comes from Git itself, and is related
to the configuration of the repository. In particular, I found
that our binutils-gdb repository's configuration has:

| [receive]
|         denynonfastforwards = true

Not sure what the history of this is.

In the meantime, I've modified the git-hooks configuration so that,
if the above is lifted, users will be allowed to do non-fast-forward
updates on users/.* branches.

-- 
Joel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Please enable fast forward for user branches
  2021-03-30  4:09 ` Please enable fast forward for user branches Joel Brobecker
@ 2021-03-30  5:36   ` Mike Frysinger via Gdb-patches
  2021-03-30  6:17     ` Joel Brobecker
  0 siblings, 1 reply; 5+ messages in thread
From: Mike Frysinger via Gdb-patches @ 2021-03-30  5:36 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Binutils, gdb-patches

On 30 Mar 2021 08:09, Joel Brobecker wrote:
> > I would like to sync up my binutils user branches to the primary server.
> > However, I can't do rebases which makes it not usable at all:
> > 
> > $ git push origin me/startswith -f
> > Enumerating objects: 257, done.
> > Counting objects: 100% (257/257), done.
> > Delta compression using up to 16 threads
> > Compressing objects: 100% (140/140), done.
> > Writing objects: 100% (140/140), 22.31 KiB | 951.00 KiB/s, done.
> > Total 140 (delta 134), reused 0 (delta 0), pack-reused 0
> > remote: Resolving deltas: 100% (134/134), completed with 117 local objects.
> > remote: error: denying non-fast-forward refs/heads/users/marxin/startswith (you should pull first)
> > To ssh://sourceware.org/git/binutils-gdb.git
> >  ! [remote rejected]         me/startswith -> users/marxin/startswith (non-fast-forward)
> > error: failed to push some refs to 'ssh://sourceware.org/git/binutils-gdb.git'
> 
> I think the error above comes from Git itself, and is related
> to the configuration of the repository. In particular, I found
> that our binutils-gdb repository's configuration has:
> 
> | [receive]
> |         denynonfastforwards = true
> 
> Not sure what the history of this is.
> 
> In the meantime, I've modified the git-hooks configuration so that,
> if the above is lifted, users will be allowed to do non-fast-forward
> updates on users/.* branches.

iiuc, out of the box, the default git implementation has one knob for all
branches (the one you found).  we set it that way so people don't push
non-fast-forwards to the important branches (e.g. "master" or any of the
many release branches).  that all makes perfect sense -- we don't want
people to accidentally, or on purpose, rewrite (i.e. rewind) history once
it's gone public.

unfortunately, the default git configs don't have ref filtering to allow
denynonfastforwards=false on refs/heads/users/*.  any services that have
that functionality implemented it themselves.  which is what we'd have to
do with custom git hooks if we wanted to.  but it looks like no one has
volunteered to implement the hook to block most refs by default but only
allow a specific subset.  probably because they don't want to be on the
hook for when it needs debugging.
-mike

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Please enable fast forward for user branches
  2021-03-30  5:36   ` Mike Frysinger via Gdb-patches
@ 2021-03-30  6:17     ` Joel Brobecker
  2021-03-30 11:53       ` Mike Frysinger via Gdb-patches
  0 siblings, 1 reply; 5+ messages in thread
From: Joel Brobecker @ 2021-03-30  6:17 UTC (permalink / raw)
  To: Martin Liška, Binutils, gdb-patches

> > I think the error above comes from Git itself, and is related
> > to the configuration of the repository. In particular, I found
> > that our binutils-gdb repository's configuration has:
> > 
> > | [receive]
> > |         denynonfastforwards = true
> > 
> > Not sure what the history of this is.
> > 
> > In the meantime, I've modified the git-hooks configuration so that,
> > if the above is lifted, users will be allowed to do non-fast-forward
> > updates on users/.* branches.
> 
> iiuc, out of the box, the default git implementation has one knob for all
> branches (the one you found).  we set it that way so people don't push
> non-fast-forwards to the important branches (e.g. "master" or any of the
> many release branches).  that all makes perfect sense -- we don't want
> people to accidentally, or on purpose, rewrite (i.e. rewind) history once
> it's gone public.
> 
> unfortunately, the default git configs don't have ref filtering to allow
> denynonfastforwards=false on refs/heads/users/*.  any services that have
> that functionality implemented it themselves.  which is what we'd have to
> do with custom git hooks if we wanted to.  but it looks like no one has
> volunteered to implement the hook to block most refs by default but only
> allow a specific subset.  probably because they don't want to be on the
> hook for when it needs debugging.

Actually, we do use the git-hooks (https://github.com/adacore/git-hooks)
which allow per-reference configuration of that restriction. That's
what I was trying to explain in my message.

Perhaps the receive.denynonfastforwards  pre-dates the use of
the git-hooks.

-- 
Joel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Please enable fast forward for user branches
  2021-03-30  6:17     ` Joel Brobecker
@ 2021-03-30 11:53       ` Mike Frysinger via Gdb-patches
  2021-03-30 12:52         ` Joel Brobecker
  0 siblings, 1 reply; 5+ messages in thread
From: Mike Frysinger via Gdb-patches @ 2021-03-30 11:53 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Binutils, gdb-patches

On 30 Mar 2021 10:17, Joel Brobecker wrote:
> Actually, we do use the git-hooks (https://github.com/adacore/git-hooks)
> which allow per-reference configuration of that restriction. That's
> what I was trying to explain in my message.

gotcha

iiuc, the hooks are only accessible to a handful of devs who have admin
access (i.e. ssh terminal on sourceware.org).  could we move these to
git themselves ?  in past admin roles, i'd setup the hooks as yet another
git repo for people to clone so people could send patches, or if review
systems were available, to send PR's.  only admins could approve, but
everyone could still contribute & review directly.
-mike

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Please enable fast forward for user branches
  2021-03-30 11:53       ` Mike Frysinger via Gdb-patches
@ 2021-03-30 12:52         ` Joel Brobecker
  0 siblings, 0 replies; 5+ messages in thread
From: Joel Brobecker @ 2021-03-30 12:52 UTC (permalink / raw)
  To: Martin Liška, Binutils, gdb-patches

> > Actually, we do use the git-hooks (https://github.com/adacore/git-hooks)
> > which allow per-reference configuration of that restriction. That's
> > what I was trying to explain in my message.
> 
> gotcha
> 
> iiuc, the hooks are only accessible to a handful of devs who have admin
> access (i.e. ssh terminal on sourceware.org).  could we move these to
> git themselves ?  in past admin roles, i'd setup the hooks as yet another
> git repo for people to clone so people could send patches, or if review
> systems were available, to send PR's.  only admins could approve, but
> everyone could still contribute & review directly.

The configuration is actually already accessible through Git,
inside the repository itself. The location is inspired from Gerrit:
It's in a file called project.config in the special reference
refs/meta/config.

The hooks themselves are under GitHub, and there is what I hope
a good reference README.md file that explains how to use the hooks.

-- 
Joel

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-03-30 12:52 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1af95023-580d-6774-c307-1a38bf3dc073@suse.cz>
2021-03-30  4:09 ` Please enable fast forward for user branches Joel Brobecker
2021-03-30  5:36   ` Mike Frysinger via Gdb-patches
2021-03-30  6:17     ` Joel Brobecker
2021-03-30 11:53       ` Mike Frysinger via Gdb-patches
2021-03-30 12:52         ` Joel Brobecker

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox