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