Re: Potentially dangerous behavior of git gc

From: Sergio <sergio.callegari@gmail.com>
Date: Oct 20, 2009, 11:40 UTC
Message-ID: <loom.20091020T132839-911@post.gmane.org>
In-Reply-To: <20091019112153.GX6115@genesis.frugalware.org>

Miklos Vajna <vmiklos <at> frugalware.org> writes:

> 
> On Mon, Oct 19, 2009 at 08:04:58AM +0000, Sergio Callegari

<sergio.callegari <at> gmail.com> wrote:

> > With this when the alternate info of A is finally updated, A is broken,

missing

> > many references and not having a head anymore.
> > 
> > Would it be better to have git gc not to take dangerous actions on

potentially

Show 6 quoted lines

> > problematic repos?
> 
> Such repos are usually created using git clone -s. See the NOTE of the
> manpage under the -s option, probably you want to use git repack -a
> after git clone.
>

Thanks, unfortunately, that was not really my point. But I now see that I cannot create a test case to reproduce my issue. Briefly what happened to me is the following

1) Create repo A
2) Clone with -s A into B
3) Do some work in B, being happy of maintaining the alternate
4) At some point, move A elsewhere
5) Do a couple of things in B, including a git gc, before realizing that
   moving A had created problems to B
6) Rush to make A reachable by B again by updating the info/alternates
   file in B
7) Realize that in spite of 6) B is gone... no more ref/heads/master, git
   thinks that this is a new empty repo.

And certainly the fault was of some of the "two things" done in 5). At the beginning I thought that the blame was of git gc, but I see that I cannot reproduce the situation at all with test cases.

So I will give up for now... I'll get back to it if I ever have a similar problem. Once more, sorry for the noise.

Sergio