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

[Jeff King <peff@peff.net>]

On Mon, Nov 21, 2011 at 05:09:23PM -0500, Phillip Susi wrote:

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

Yes, that is one way to do it. The big drawback there is that by using
hard links, you can only share objects between repos within the same
filesystem.

I think the presence of the '.keep' files should make "git gc" do the
right thing, and not waste space. The relinking procedure is a little
more complex, but that's not a big deal. It's just a periodic
maintenance thing that will happen inside a script (and you would want
to do the periodic maintenance as often as you would with the shared
repo approach).

Nothing is maintaining the list of "here are all of the related repos
that are sharing objects".  Which is a feature in some ways, because you
don't have to care if repos go away or move. But when your periodic "git
relink" comes around, the burden is on the user to redecide the set of
related repos.

So unlike with the shared repo, where "git gc" in a child repo could say
"Oh, I have a shared parent; I should go there and do the parent-gc
there", relinking would be a more manual thing. On the other hand,
nothing is stopping you from building something more automated around
this relink-repos-together building block.

So yeah, I think it's a perfectly reasonable approach, if you don't mind
the hard link requirement, and your relink is something like "git relink
~/linux-repos/*".

Patches? :)

-Peff