Re: [RFC] deprecating and eventually removing "git relink"?

[Phillip Susi <psusi@cfl.rr.com>]

On 11/14/2011 5:34 AM, Jeff King wrote:
> One issue with this scheme (or most similar schemes) is that child repos
> are uniquely identified by their directory name. In the absence of
> alternates, it's perfectly reasonable to do:
>
>    git init; hack hack hack; commit commit commit
>    cd .. ; mv project new-project-name
>
> but here it would break the shared repo's link to the child (which is
> not just inconvenient, but dangerous, as we will not respect its refs
> when pruning). Probably the "warning" above should actually error out
> and force the user to say "yes, I deleted this child" or "no, I moved it
> here".

I hacked together a setup a few weeks ago that doesn't suffer from that 
problem.  I had two repos that had considerable shared history ( one 
forked from the other ), so I created a temporary repository and pointed 
its alternates to the other two.  I then did some shell magic to 
generate a list of all objects shared by both repos, and sent that list 
to git-pack-objects.  This gave me a pack file in the temp repo that 
contained all of the shared objects.  I then made a .keep file and hard 
linked this pack file ( and index, and .keep file ) into both original 
repos, deleted the temp repo, and then repacked both original repos. 
This left them both with two pack files: one that is shared, and one 
that is all of the objects specific to that repo.

Because the shared objects are in a pack file that both repos hard link 
to, neither one will break if I (re)move the other.  It would be nice if 
git relink could be enhanced to do this, then you can just periodically 
run relink with a list of repos and it could hard link all of the shared 
data into a big shared pack file, with no need to have a "master" repo 
that requires special handling.