Re: RFE: git relink
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:41:59
quoted
quoted
quoted
quoted
"JG" == Jeff Garzik [off-list ref] writes:
JG> It would be nice if somebody were motivated enough to create a command JG> that functions like: JG> git relink repoA repoB repoC repoD... repoX JG> which would examine JG> repoA/.git JG> repoB/.git JG> repoC/.git JG> repoD/.git JG> and verify (updating, if necessary) that each of the A/B/C/D repos are JG> hardlinked to repoX. Whoever is doing this script needs to be a bit careful. If you end up unlinking a full object and hard-linking a deltified object representation (delta) in its place, the repository can get corrupted, because it might not have the necessary base object for the delta. There are two strategies to solve this. Either (1) the relinker refuses to replace a full object with a delta, or (2) the relinker notices a delta, and makes an additional hard link to the base object when replacing a full object with a delta (this needs to be done recursively until you hit a full base object). (1) is simpler and cleaner, but does not get full advantage of the delta compression. (2) gives you delta compression but it will add possibly "unwanted" objects to a repository that happens to slurp in a delta (fsck would not complain, though). My knee-jerk vote goes to (1), but in either case the relinker needs to check if it is dealing with a delta; this cannot be done with git-cat-file -t AFAIK. Ryan Anderson code will notice delta vs full object case most of the time because it checks and makes sure the sizes of corresponding files from two repositories match. The problem with the code is that it dies, instead of just ignoring, when size differs. Dying is good for ordinary case (two full object representations of the same file should not have different sizes), but it is not the right thing to do when it sees one side using the full object representation and the other side using a delta.