{"thread":{"id":"43462","subject":"Re: Overwriting bare repositories' master","startedAt":"2006-10-29T21:03:33Z","lastAt":"2006-10-29T22:43:07Z","messageCount":6,"participants":["Junio C Hamano","Sylvain Beucler","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296491","messageId":"20061029210333.GG12285@localhost.localdomain","threadId":"43462","inReplyTo":null,"subject":"Overwriting bare repositories' master","fromName":"Sylvain Beucler","fromEmail":"beuc@gnu.org","sentAt":"2006-10-29T21:03:33Z","receivedAt":"2006-10-29T21:03:33Z","isPatch":false,"sender":{"key":"beuc@gnu.org","avatar":null},"body":"Hello,\n\nI'm trying to setup a git hosting facility, such as repo.or.cz. The\nfacility provides a pre-initialized git repository only accessible\nthrough git-shell.\n\nThe goal is to minimise the system admins' intervention, and I have a\nquestion about a branch 'overwriting'. For example, let's say the user\nmakes an initial import to refs/heads/master for testing purposes,\nthen wants to start over and import the real project. Can he put a\nwholy different git repository in place of the other one, at the same\ndestination?\n\nI tried and I found something that doesn't seem to follow the\ndocumentation:\n\nrepo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \\\n master:refs/heads/master\n# [OK]\nrepo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \\\n +refs/heads/master:refs/heads/master\nupdating 'refs/heads/master'\n from ee3bda653dfabaf0f78f2a9977abec180f2b19dc\n to c9a726b610bafc82142a16af80b83d28375ca619\nGenerating pack...\nDone counting 0 objects.\nTotal 0, written 0 (delta 0), reused 0 (delta 0)\nUnpacking 0 objects\nerror: denying non-fast forward; you should pull first\n\nFrom man git-push:\n\"If the optional plus + is used, the remote ref is updated even if it\ndoes not result in a fast forward update.\"\n\nThis also makes one wonder how the 'pu' git branch is updated.\n\n\nOne the one hand, this means that sysadmin intervention is required to\nreset such a repository, which is bad. One the other hand, this is\nalso a security because users cannot erase history, even if there a\ncron job to prune&pack the git repositories, which is good.\n\nIs this by design? Or should it work?\n\n-- \n"},{"id":"296143","messageId":"20061029215758.GA24385@localhost.localdomain","threadId":"43462","inReplyTo":"20061029210333.GG12285@localhost.localdomain","subject":"Re: Overwriting bare repositories' master","fromName":"Sylvain Beucler","fromEmail":"beuc@gnu.org","sentAt":"2006-10-29T21:57:58Z","receivedAt":"2006-10-29T21:57:58Z","isPatch":false,"sender":{"key":"beuc@gnu.org","avatar":null},"body":"ShadeHawk at #git noticed that this does not apply for a local\ndirectory.\n\nI reproduced the two successive push-es both to a local git\nrepository, and then to a remote git-shell'd one, and indeed, it works\nlocally but it is rejected remotely (\"error: denying non-fast forward;\nyou should pull first\").\n\nSo this is probably caused by git-shell restrictions.\n\nFeature? :)\n\n-- \nSylvain\n\n\nOn Sun, Oct 29, 2006 at 10:03:33PM +0100, Sylvain Beucler wrote:\n> Hello,\n> \n> I'm trying to setup a git hosting facility, such as repo.or.cz. The\n> facility provides a pre-initialized git repository only accessible\n> through git-shell.\n> \n> The goal is to minimise the system admins' intervention, and I have a\n> question about a branch 'overwriting'. For example, let's say the user\n> makes an initial import to refs/heads/master for testing purposes,\n> then wants to start over and import the real project. Can he put a\n> wholy different git repository in place of the other one, at the same\n> destination?\n> \n> I tried and I found something that doesn't seem to follow the\n> documentation:\n> \n> repo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \\\n> master:refs/heads/master\n> # [OK]\n> repo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \\\n> +refs/heads/master:refs/heads/master\n> updating 'refs/heads/master'\n> from ee3bda653dfabaf0f78f2a9977abec180f2b19dc\n> to c9a726b610bafc82142a16af80b83d28375ca619\n> Generating pack...\n> Done counting 0 objects.\n> Total 0, written 0 (delta 0), reused 0 (delta 0)\n> Unpacking 0 objects\n> error: denying non-fast forward; you should pull first\n> \n> From man git-push:\n> \"If the optional plus + is used, the remote ref is updated even if it\n> does not result in a fast forward update.\"\n> \n> This also makes one wonder how the 'pu' git branch is updated.\n> \n> \n> One the one hand, this means that sysadmin intervention is required to\n> reset such a repository, which is bad. One the other hand, this is\n> also a security because users cannot erase history, even if there a\n> cron job to prune&pack the git repositories, which is good.\n> \n"},{"id":"294898","messageId":"7vslh6zstt.fsf@assigned-by-dhcp.cox.net","threadId":"43462","inReplyTo":"20061029210333.GG12285@localhost.localdomain","subject":"Re: Overwriting bare repositories' master","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-29T21:59:42Z","receivedAt":"2006-10-29T21:59:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sylvain Beucler writes:\n\n> I tried and I found something that doesn't seem to follow the\n> documentation:\n>\n> repo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \\\n> master:refs/heads/master\n> # [OK]\n> repo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \\\n> +refs/heads/master:refs/heads/master\n> updating 'refs/heads/master'\n> from ee3bda653dfabaf0f78f2a9977abec180f2b19dc\n> to c9a726b610bafc82142a16af80b83d28375ca619\n> Generating pack...\n> Done counting 0 objects.\n> Total 0, written 0 (delta 0), reused 0 (delta 0)\n> Unpacking 0 objects\n> error: denying non-fast forward; you should pull first\n>\n> From man git-push:\n> \"If the optional plus + is used, the remote ref is updated even if it\n> does not result in a fast forward update.\"\n>\n> This also makes one wonder how the 'pu' git branch is updated.\n>\n> One the one hand, this means that sysadmin intervention is required to\n> reset such a repository, which is bad. One the other hand, this is\n> also a security because users cannot erase history, even if there a\n> cron job to prune&pack the git repositories, which is good.\n>\n> Is this by design? Or should it work?\n\nI suspect (because I cannot see your .git/config in the\nrepository; which would say \"[core] sharedrepository = 1\" if my\nsuspicion is correct) that this is fairly new heavyhanded safety\nvalve added by the list around mid September, with this:\n\n commit 11031d7e9f34f6a20ff4a4bd4fa3e5e3c0024a57\n Author: Johannes Schindelin \n Date: Thu Sep 21 01:07:54 2006 +0200\n\n add receive.denyNonFastforwards config variable\n\n If receive.denyNonFastforwards is set to true,\n git-receive-pack will deny non fast-forwards, i.e. forced\n updates. Most notably, a push to a repository which has that\n flag set will fail.\n\n As a first user, 'git-init-db --shared' sets this flag,\n since in a shared setup, you are most unlikely to want\n forced pushes to succeed.\n\nThe reasoning is exactly as you guessed.\n\nI think the intention of the patch is that the repository\nadministrators are expected to either (1) adjust the\nnon-fast-forwarding branch to fast-forward (by reset --hard to\nan ancestor of what you are trying to push into), (2)\ntemporarily disable the safety value by editing .git/config, or\n(3) instead of pushing into it, force fetching into it from the\nrepository machine.\n\nIt is doing what it was designed to do. It is a different issue\nif the design is good, but rewinding the public branch is not\nsomething even a repository administrator should take lightly\nand not expected to happen often (except in cases like yours\nwhere the administrator is tipping his toe into the water), so I\nthink overall the current behaviour is an acceptable balance\nbetween safety and convenience.\n\nMy public repository is not shared (only I can push into it) so\nthis is a non-issue for my 'pu' branch.\n"},{"id":"295117","messageId":"7vlkmyzsk0.fsf@assigned-by-dhcp.cox.net","threadId":"43462","inReplyTo":"20061029215758.GA24385@localhost.localdomain","subject":"Re: Overwriting bare repositories' master","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-29T22:05:35Z","receivedAt":"2006-10-29T22:05:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sylvain Beucler writes:\n\n> ShadeHawk at #git noticed that this does not apply for a local\n> directory.\n\nDo not top-post please.\n\n> I reproduced the two successive push-es both to a local git\n> repository, and then to a remote git-shell'd one, and indeed, it works\n> locally but it is rejected remotely (\"error: denying non-fast forward;\n> you should pull first\").\n>\n> So this is probably caused by git-shell restrictions.\n\nI do not think so. Have you checked your config to see if you\nhave receive.denyNonFastforwards set?\n\nI suspect Jakub (ShadeHawk)'s test does not have it.\n\n\n\n"},{"id":"297215","messageId":"20061029222151.GB24385@localhost.localdomain","threadId":"43462","inReplyTo":"7vslh6zstt.fsf@assigned-by-dhcp.cox.net","subject":"Re: Overwriting bare repositories' master","fromName":"Sylvain Beucler","fromEmail":"beuc@gnu.org","sentAt":"2006-10-29T22:21:51Z","receivedAt":"2006-10-29T22:21:51Z","isPatch":false,"sender":{"key":"beuc@gnu.org","avatar":null},"body":"On Sun, Oct 29, 2006 at 01:59:42PM -0800, Junio C Hamano wrote:\n> Sylvain Beucler writes:\n> \n> > I tried and I found something that doesn't seem to follow the\n> > documentation:\n> >\n> > repo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \\\n> > master:refs/heads/master\n> > # [OK]\n> > repo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \\\n> > +refs/heads/master:refs/heads/master\n> > updating 'refs/heads/master'\n> > from ee3bda653dfabaf0f78f2a9977abec180f2b19dc\n> > to c9a726b610bafc82142a16af80b83d28375ca619\n> > Generating pack...\n> > Done counting 0 objects.\n> > Total 0, written 0 (delta 0), reused 0 (delta 0)\n> > Unpacking 0 objects\n> > error: denying non-fast forward; you should pull first\n> >\n> > From man git-push:\n> > \"If the optional plus + is used, the remote ref is updated even if it\n> > does not result in a fast forward update.\"\n> >\n> > This also makes one wonder how the 'pu' git branch is updated.\n> >\n> > One the one hand, this means that sysadmin intervention is required to\n> > reset such a repository, which is bad. One the other hand, this is\n> > also a security because users cannot erase history, even if there a\n> > cron job to prune&pack the git repositories, which is good.\n> >\n> > Is this by design? Or should it work?\n> \n> I suspect (because I cannot see your .git/config in the\n> repository; which would say \"[core] sharedrepository = 1\" if my\n> suspicion is correct) that this is fairly new heavyhanded safety\n> valve added by the list around mid September, with this:\n> \n> commit 11031d7e9f34f6a20ff4a4bd4fa3e5e3c0024a57\n> Author: Johannes Schindelin \n> Date: Thu Sep 21 01:07:54 2006 +0200\n> \n> add receive.denyNonFastforwards config variable\n> \n> If receive.denyNonFastforwards is set to true,\n> git-receive-pack will deny non fast-forwards, i.e. forced\n> updates. Most notably, a push to a repository which has that\n> flag set will fail.\n> \n> As a first user, 'git-init-db --shared' sets this flag,\n> since in a shared setup, you are most unlikely to want\n> forced pushes to succeed.\n> \n> The reasoning is exactly as you guessed.\n> \n> I think the intention of the patch is that the repository\n> administrators are expected to either (1) adjust the\n> non-fast-forwarding branch to fast-forward (by reset --hard to\n> an ancestor of what you are trying to push into), (2)\n> temporarily disable the safety value by editing .git/config, or\n> (3) instead of pushing into it, force fetching into it from the\n> repository machine.\n> \n> It is doing what it was designed to do. It is a different issue\n> if the design is good, but rewinding the public branch is not\n> something even a repository administrator should take lightly\n> and not expected to happen often (except in cases like yours\n> where the administrator is tipping his toe into the water), so I\n> think overall the current behaviour is an acceptable balance\n> between safety and convenience.\n> \n> My public repository is not shared (only I can push into it) so\n> this is a non-issue for my 'pu' branch.\n\n\nYou perfectly guessed the situation.\n\nSetting denyNonFastforwards=false allowed the forced push to succeed.\nFor reference the config file was\n(http://cvs.sv.gnu.org/r/test.git/config):\n[core]\n\trepositoryformatversion = 0\n\tfilemode = true\n\tsharedrepository = 1\n[receive]\n\tdenyNonFastforwards = true\n\nThis sounds like a sound design :)\n\n-- \n"},{"id":"296794","messageId":"Pine.LNX.4.63.0610292338300.26682@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43462","inReplyTo":"7vslh6zstt.fsf@assigned-by-dhcp.cox.net","subject":"Re: Overwriting bare repositories' master","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-29T22:43:07Z","receivedAt":"2006-10-29T22:43:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 29 Oct 2006, Junio C Hamano wrote:\n\n> Sylvain Beucler writes:\n> \n> > I tried and I found something that doesn't seem to follow the\n> > documentation:\n> >\n> > [...]\n> > error: denying non-fast forward; you should pull first\n> >\n> > From man git-push:\n> > \"If the optional plus + is used, the remote ref is updated even if it\n> > does not result in a fast forward update.\"\n> >\n> > [...]\n> >\n> > Is this by design? Or should it work?\n> \n> I suspect (because I cannot see your .git/config in the\n> repository; which would say \"[core] sharedrepository = 1\" if my\n> suspicion is correct) that this is fairly new heavyhanded safety\n> valve added by the list around mid September, with this:\n> \n> commit 11031d7e9f34f6a20ff4a4bd4fa3e5e3c0024a57\n> Author: Johannes Schindelin \n> Date: Thu Sep 21 01:07:54 2006 +0200\n> \n> add receive.denyNonFastforwards config variable\n> [...]\n\nI still think the forced updates of pu still lose too many useful bits in \ngit's history.\n\nHaving said that, if receive.denyNonFastforwards indeed is the culprit: \ngit-shell allows you to do something like this:\n\n\tssh user@git.gnu.org \\\n\t \"git-repo-config --unset receive.denyNonFastforwards\"\n\nAfter that, forced pushes should succeed. By the same account,\n\n\tssh user@git.gnu.org \\\n\t \"git-repo-config --bool receive.denyNonFastforwards\"\n\nshould tell you if Junio's suggestion is right (in this case, it will \noutput \"true\").\n\nHth,\nDscho\n"}]}