threads / discuss / 21278

Potentially dangerous behavior of git gc

Subject: Potentially dangerous behavior of git gc

## tl;dr

3 messages between Oct 19, 2009 and Oct 20, 2009.

replies: 2people: 2as markdown or json

Sergio Callegari· Oct 19, 2009, 08:04 UTC · lore

Hi,

I encountered an issue with git gc.

Consider the following scenario. Repo A is using repo B as an alternate object database through the .git/objects/info/alternates mechanism. B is at /some_path/B. A has some references, including HEAD that are pointing at objects that are in fact in the object database of B.

For some reasons, paths are modified on the machine, so that B gets moved at /some_new_path/B.

Obviously A cannot find its objects anymore and its alternate info should be updated.

Suppose that now one runs git gc on A.

Correctly git gc complains about the broken alternate link. And then complains again as it cannot find some objects.

However, rather than trying to preserve the repo integrity, it then _removes_ all the references pointing to non existing objects.

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?

Thanks

Sergio

Miklos Vajna· Oct 19, 2009, 11:21 UTC · re: Sergio Callegari · lore

Re: Potentially dangerous behavior of git gc

On Mon, Oct 19, 2009 at 08:04:58AM +0000, Sergio Callegari <sergio.callegari@gmail.com> wrote:

Show 5 quoted lines

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

Sergio· Oct 20, 2009, 11:40 UTC · re: Miklos Vajna · lore

Re: Potentially dangerous behavior of git gc

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