Overwriting bare repositories' master

Overwriting bare repositories' master

[Sylvain Beucler]

Hello,

I'm trying to setup a git hosting facility, such as repo.or.cz. The
facility provides a pre-initialized git repository only accessible
through git-shell.

The goal is to minimise the system admins' intervention, and I have a
question about a branch 'overwriting'. For example, let's say the user
makes an initial import to refs/heads/master for testing purposes,
then wants to start over and import the real project. Can he put a
wholy different git repository in place of the other one, at the same
destination?

I tried and I found something that doesn't seem to follow the
documentation:

repo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \
  master:refs/heads/master
# [OK]
repo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \
  +refs/heads/master:refs/heads/master
updating 'refs/heads/master'
  from ee3bda653dfabaf0f78f2a9977abec180f2b19dc
  to   c9a726b610bafc82142a16af80b83d28375ca619
Generating pack...
Done counting 0 objects.
Total 0, written 0 (delta 0), reused 0 (delta 0)
Unpacking 0 objects
error: denying non-fast forward; you should pull first

From man git-push:
"If the optional plus + is used, the remote ref is updated even if it
does not result in a fast forward update."

This also makes one wonder how the 'pu' git branch is updated.


One the one hand, this means that sysadmin intervention is required to
reset such a repository, which is bad. One the other hand, this is
also a security because users cannot erase history, even if there a
cron job to prune&pack the git repositories, which is good.

Is this by design? Or should it work?

-- 

Re: Overwriting bare repositories' master

[Sylvain Beucler]

ShadeHawk at #git noticed that this does not apply for a local
directory.

I reproduced the two successive push-es both to a local git
repository, and then to a remote git-shell'd one, and indeed, it works
locally but it is rejected remotely ("error: denying non-fast forward;
you should pull first").

So this is probably caused by git-shell restrictions.

Feature? :)

-- 
Sylvain


On Sun, Oct 29, 2006 at 10:03:33PM +0100, Sylvain Beucler wrote:
> Hello,
> 
> I'm trying to setup a git hosting facility, such as repo.or.cz. The
> facility provides a pre-initialized git repository only accessible
> through git-shell.
> 
> The goal is to minimise the system admins' intervention, and I have a
> question about a branch 'overwriting'. For example, let's say the user
> makes an initial import to refs/heads/master for testing purposes,
> then wants to start over and import the real project. Can he put a
> wholy different git repository in place of the other one, at the same
> destination?
> 
> I tried and I found something that doesn't seem to follow the
> documentation:
> 
> repo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \
>   master:refs/heads/master
> # [OK]
> repo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \
>   +refs/heads/master:refs/heads/master
> updating 'refs/heads/master'
>   from ee3bda653dfabaf0f78f2a9977abec180f2b19dc
>   to   c9a726b610bafc82142a16af80b83d28375ca619
> Generating pack...
> Done counting 0 objects.
> Total 0, written 0 (delta 0), reused 0 (delta 0)
> Unpacking 0 objects
> error: denying non-fast forward; you should pull first
> 
> From man git-push:
> "If the optional plus + is used, the remote ref is updated even if it
> does not result in a fast forward update."
> 
> This also makes one wonder how the 'pu' git branch is updated.
> 
> 
> One the one hand, this means that sysadmin intervention is required to
> reset such a repository, which is bad. One the other hand, this is
> also a security because users cannot erase history, even if there a
> cron job to prune&pack the git repositories, which is good.
> 

Re: Overwriting bare repositories' master

[Junio C Hamano]

Sylvain Beucler <beuc@gnu.org> writes:

> I tried and I found something that doesn't seem to follow the
> documentation:
>
> repo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \
>   master:refs/heads/master
> # [OK]
> repo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \
>   +refs/heads/master:refs/heads/master
> updating 'refs/heads/master'
>   from ee3bda653dfabaf0f78f2a9977abec180f2b19dc
>   to   c9a726b610bafc82142a16af80b83d28375ca619
> Generating pack...
> Done counting 0 objects.
> Total 0, written 0 (delta 0), reused 0 (delta 0)
> Unpacking 0 objects
> error: denying non-fast forward; you should pull first
>
> From man git-push:
> "If the optional plus + is used, the remote ref is updated even if it
> does not result in a fast forward update."
>
> This also makes one wonder how the 'pu' git branch is updated.
>
> One the one hand, this means that sysadmin intervention is required to
> reset such a repository, which is bad. One the other hand, this is
> also a security because users cannot erase history, even if there a
> cron job to prune&pack the git repositories, which is good.
>
> Is this by design? Or should it work?

I suspect (because I cannot see your .git/config in the
repository; which would say "[core] sharedrepository = 1" if my
suspicion is correct) that this is fairly new heavyhanded safety
valve added by the list around mid September, with this:

    commit 11031d7e9f34f6a20ff4a4bd4fa3e5e3c0024a57
    Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
    Date:   Thu Sep 21 01:07:54 2006 +0200

        add receive.denyNonFastforwards config variable

        If receive.denyNonFastforwards is set to true,
        git-receive-pack will deny non fast-forwards, i.e. forced
        updates. Most notably, a push to a repository which has that
        flag set will fail.

        As a first user, 'git-init-db --shared' sets this flag,
        since in a shared setup, you are most unlikely to want
        forced pushes to succeed.

The reasoning is exactly as you guessed.

I think the intention of the patch is that the repository
administrators are expected to either (1) adjust the
non-fast-forwarding branch to fast-forward (by reset --hard to
an ancestor of what you are trying to push into), (2)
temporarily disable the safety value by editing .git/config, or
(3) instead of pushing into it, force fetching into it from the
repository machine.

It is doing what it was designed to do.  It is a different issue
if the design is good, but rewinding the public branch is not
something even a repository administrator should take lightly
and not expected to happen often (except in cases like yours
where the administrator is tipping his toe into the water), so I
think overall the current behaviour is an acceptable balance
between safety and convenience.

My public repository is not shared (only I can push into it) so
this is a non-issue for my 'pu' branch.

Re: Overwriting bare repositories' master

[Junio C Hamano]

Sylvain Beucler <beuc@gnu.org> writes:

> ShadeHawk at #git noticed that this does not apply for a local
> directory.

Do not top-post please.

> I reproduced the two successive push-es both to a local git
> repository, and then to a remote git-shell'd one, and indeed, it works
> locally but it is rejected remotely ("error: denying non-fast forward;
> you should pull first").
>
> So this is probably caused by git-shell restrictions.

I do not think so.  Have you checked your config to see if you
have receive.denyNonFastforwards set?

I suspect Jakub (ShadeHawk)'s test does not have it.

Re: Overwriting bare repositories' master

[Sylvain Beucler]

On Sun, Oct 29, 2006 at 01:59:42PM -0800, Junio C Hamano wrote:
> Sylvain Beucler <beuc@gnu.org> writes:
> 
> > I tried and I found something that doesn't seem to follow the
> > documentation:
> >
> > repo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \
> >   master:refs/heads/master
> > # [OK]
> > repo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \
> >   +refs/heads/master:refs/heads/master
> > updating 'refs/heads/master'
> >   from ee3bda653dfabaf0f78f2a9977abec180f2b19dc
> >   to   c9a726b610bafc82142a16af80b83d28375ca619
> > Generating pack...
> > Done counting 0 objects.
> > Total 0, written 0 (delta 0), reused 0 (delta 0)
> > Unpacking 0 objects
> > error: denying non-fast forward; you should pull first
> >
> > From man git-push:
> > "If the optional plus + is used, the remote ref is updated even if it
> > does not result in a fast forward update."
> >
> > This also makes one wonder how the 'pu' git branch is updated.
> >
> > One the one hand, this means that sysadmin intervention is required to
> > reset such a repository, which is bad. One the other hand, this is
> > also a security because users cannot erase history, even if there a
> > cron job to prune&pack the git repositories, which is good.
> >
> > Is this by design? Or should it work?
> 
> I suspect (because I cannot see your .git/config in the
> repository; which would say "[core] sharedrepository = 1" if my
> suspicion is correct) that this is fairly new heavyhanded safety
> valve added by the list around mid September, with this:
> 
>     commit 11031d7e9f34f6a20ff4a4bd4fa3e5e3c0024a57
>     Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>     Date:   Thu Sep 21 01:07:54 2006 +0200
> 
>         add receive.denyNonFastforwards config variable
> 
>         If receive.denyNonFastforwards is set to true,
>         git-receive-pack will deny non fast-forwards, i.e. forced
>         updates. Most notably, a push to a repository which has that
>         flag set will fail.
> 
>         As a first user, 'git-init-db --shared' sets this flag,
>         since in a shared setup, you are most unlikely to want
>         forced pushes to succeed.
> 
> The reasoning is exactly as you guessed.
> 
> I think the intention of the patch is that the repository
> administrators are expected to either (1) adjust the
> non-fast-forwarding branch to fast-forward (by reset --hard to
> an ancestor of what you are trying to push into), (2)
> temporarily disable the safety value by editing .git/config, or
> (3) instead of pushing into it, force fetching into it from the
> repository machine.
> 
> It is doing what it was designed to do.  It is a different issue
> if the design is good, but rewinding the public branch is not
> something even a repository administrator should take lightly
> and not expected to happen often (except in cases like yours
> where the administrator is tipping his toe into the water), so I
> think overall the current behaviour is an acceptable balance
> between safety and convenience.
> 
> My public repository is not shared (only I can push into it) so
> this is a non-issue for my 'pu' branch.


You perfectly guessed the situation.

Setting denyNonFastforwards=false allowed the forced push to succeed.
For reference the config file was
(http://cvs.sv.gnu.org/r/test.git/config):
[core]
	repositoryformatversion = 0
	filemode = true
	sharedrepository = 1
[receive]
	denyNonFastforwards = true

This sounds like a sound design :)

-- 

Re: Overwriting bare repositories' master

[Johannes Schindelin]

Hi,

On Sun, 29 Oct 2006, Junio C Hamano wrote:

> Sylvain Beucler <beuc@gnu.org> writes:
> 
> > I tried and I found something that doesn't seem to follow the
> > documentation:
> >
> > [...]
> > error: denying non-fast forward; you should pull first
> >
> > From man git-push:
> > "If the optional plus + is used, the remote ref is updated even if it
> > does not result in a fast forward update."
> >
> > [...]
> >
> > Is this by design? Or should it work?
> 
> I suspect (because I cannot see your .git/config in the
> repository; which would say "[core] sharedrepository = 1" if my
> suspicion is correct) that this is fairly new heavyhanded safety
> valve added by the list around mid September, with this:
> 
>     commit 11031d7e9f34f6a20ff4a4bd4fa3e5e3c0024a57
>     Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>     Date:   Thu Sep 21 01:07:54 2006 +0200
> 
>         add receive.denyNonFastforwards config variable
> [...]

I still think the forced updates of pu still lose too many useful bits in 
git's history.

Having said that, if receive.denyNonFastforwards indeed is the culprit: 
git-shell allows you to do something like this:

	ssh user@git.gnu.org \
	  "git-repo-config --unset receive.denyNonFastforwards"

After that, forced pushes should succeed. By the same account,

	ssh user@git.gnu.org \
	  "git-repo-config --bool receive.denyNonFastforwards"

should tell you if Junio's suggestion is right (in this case, it will 
output "true").

Hth,
Dscho