On Sun, Oct 29, 2006 at 01:59:42PM -0800, Junio C Hamano wrote: > Sylvain Beucler <beuc@xxxxxxx> writes: > > > I tried and I found something that doesn't seem to follow the > > documentation: > > > > repo_one$ git push Beuc@xxxxxxxxxxxxxx:/srv/git/sources/administration.git \ > > master:refs/heads/master > > # [OK] > > repo_two$ git push --force Beuc@xxxxxxxxxxxxxx:/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@xxxxxx> > 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 :) -- Sylvain - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html