Re: Potentially dangerous behavior of git gc

[Sergio <sergio.callegari@gmail.com>]

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
> > 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