Re: Overwriting bare repositories' master

From: Sylvain Beucler <beuc@gnu.org>
Date: Oct 29, 2006, 21:57 UTC
Message-ID: <20061029215758.GA24385@localhost.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.
>