Potentially dangerous behavior of git gc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]