Re: Please enable fast forward for user branches

[Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org>]

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