# Re: Overwriting bare repositories' master 6 messages from 2006-10-29 to 2006-10-29. Participants: Junio C Hamano, Sylvain Beucler, Johannes Schindelin. Thread: https://gitlist.dev/t/43462 ## Sylvain Beucler, 2006-10-29 21:03 Subject: Overwriting bare repositories' master Message-ID: <20061029210333.GG12285@localhost.localdomain> URL: https://gitlist.dev/e/20061029210333.GG12285%40localhost.localdomain ``` 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? -- ``` ## Sylvain Beucler, 2006-10-29 21:57 Subject: Re: Overwriting bare repositories' master Message-ID: <20061029215758.GA24385@localhost.localdomain> URL: https://gitlist.dev/e/20061029215758.GA24385%40localhost.localdomain In-Reply-To: <20061029210333.GG12285@localhost.localdomain> ``` 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. > ``` ## Junio C Hamano, 2006-10-29 21:59 Subject: Re: Overwriting bare repositories' master Message-ID: <7vslh6zstt.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vslh6zstt.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061029210333.GG12285@localhost.localdomain> ``` Sylvain Beucler 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 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. ``` ## Junio C Hamano, 2006-10-29 22:05 Subject: Re: Overwriting bare repositories' master Message-ID: <7vlkmyzsk0.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vlkmyzsk0.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20061029215758.GA24385@localhost.localdomain> ``` Sylvain Beucler 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. ``` ## Sylvain Beucler, 2006-10-29 22:21 Subject: Re: Overwriting bare repositories' master Message-ID: <20061029222151.GB24385@localhost.localdomain> URL: https://gitlist.dev/e/20061029222151.GB24385%40localhost.localdomain In-Reply-To: <7vslh6zstt.fsf@assigned-by-dhcp.cox.net> ``` On Sun, Oct 29, 2006 at 01:59:42PM -0800, Junio C Hamano wrote: > Sylvain Beucler 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 > 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 :) -- ``` ## Johannes Schindelin, 2006-10-29 22:43 Subject: Re: Overwriting bare repositories' master Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0610292338300.26682%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7vslh6zstt.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Sun, 29 Oct 2006, Junio C Hamano wrote: > Sylvain Beucler 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 > 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 ```