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

From: Simon Brenner <olsner@gmail.com>
Date: Nov 14, 2011, 08:48 UTC
Message-ID: <CAD=rjTXgH+AivmK+zLurQVC+=p1UYqFy_p=wBF-1-TOQ=Cqjtw@mail.gmail.com>
In-Reply-To: <buomxbzutjm.fsf@dhlpc061.dev.necel.com>

I think one of the most annoying aspects of alternates (beyond the hassle of adding/removing them except using clone --reference) is the danger of losing data if you aren't absolutely sure that your alternate is stable and won't ever lose references to objects.

If the alternate just had links to the referring repositories, I think this hole could be neatly closed.

On Mon, Nov 14, 2011 at 7:06 AM, Miles Bader <miles@gnu.org> wrote:

Show 5 quoted lines

> It might be nice to have a mechanism where new objects would update
> the _alternate_ rather than the object-store in the tree where the
> command was run... then you could easily have a bunch of trees using a
> central object store without needing to update the central store
> occasionally by hand (and do gc in its "clients")...

This sounds like a nice way forward: replace/extend the current alternates system with support for a shared object store that is "intelligently" shared so that it can be gc:d based on all refs from all referring repositories. I imagine it would be something very much like a bare repository - except it wouldn't have any refs of its own, just a list of other repositories it should search for refs when GC:ing.

The object store currently built into each git repository could even become a special case of that: a shared object store (that happens to reside under .git) with a single referring repository (the parent .git dir). If the location of the object store is configurable, clone --reference could simply point the new repository directly to the shared store instead of ever setting up a local object store.

// Simon