Re: RFE: git relink

[Junio C Hamano <junkio@cox.net>]

>>>>> "JG" == Jeff Garzik <jgarzik@pobox.com> 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.