Please enable fast forward for user branches

Please enable fast forward for user branches

[Martin Liška]

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'

Thanks,
Martin

Re: Please enable fast forward for user branches

[Nick Alcock]

On 23 Mar 2021, Martin Liška verbalised:

> 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'

This is easy enough to work around, if annoyingly fiddly:

git push origin :users/marxin/startswith && git push origin me/startswith:users/marxin/startswith

(It's easy enough to script something that turns a forcepush into this
by looking at the branch's configured upstream.)

-- 
NULL && (void)

Re: Please enable fast forward for user branches

[Martin Liška]

On 3/24/21 2:21 AM, Nick Alcock wrote:
> On 23 Mar 2021, Martin Liška verbalised:
> 
>> 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'
> 
> This is easy enough to work around, if annoyingly fiddly:
> 
> git push origin :users/marxin/startswith && git push origin me/startswith:users/marxin/startswith
> 
> (It's easy enough to script something that turns a forcepush into this
> by looking at the branch's configured upstream.)
> 

Thanks, works for me.

Martin

Re: Please enable fast forward for user branches

[Joel Brobecker]

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

Re: Please enable fast forward for user branches

[Mike Frysinger]

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

Re: Please enable fast forward for user branches

[Joel Brobecker]

> > 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

Re: Please enable fast forward for user branches

[Mike Frysinger]

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

Re: Please enable fast forward for user branches

[Joel Brobecker]

> > 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