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

From: Jeff King <peff@peff.net>
Date: Nov 14, 2011, 20:25 UTC
Message-ID: <20111114202522.GA26269@sigill.intra.peff.net>
In-Reply-To: <7vfwhqjw4u.fsf@alter.siamese.dyndns.org>

On Mon, Nov 14, 2011 at 12:18:25PM -0800, Junio C Hamano wrote:

Show 10 quoted lines

> > Yes, I think that is sensible. I'm not sure there is even any core git
> > code to be written. I think a wrapper that does the following would
> > probably work:
> 
> I agree with your outline, which I find is in line with what I had in mind
> in the message Miles responded.
> 
> The approach is different from what Miles alluded to, which is to have
> "clients" create objects in the "central" place in the first place,
> though.

It seems to me that is simply an optimization that can come later. An initial, no-C-code implementation would write to individual repos as usual, and then occasionally migrate objects to the master shared repo (and remove duplicates from individual repos). That's an easy to implement low-risk experiment from which we can draw conclusions about how well such a system works in practice.

And then if it seems like a good path, an obvious optimization[1] is to write directly into the parent object store, skipping the migration. This might involve git-core code, or maybe it just means setting up the repos differently (e.g., symlinking the objects directory to the master store).

-Peff

[1] Actually, I am slightly dubious that this optimization is worth doing. It seems like it would save you from writing the data only to copy it later. But in practice, we write loose objects, and you are already rewriting the data to migrate it into packfiles. So the migration already happens, and instead we would just be migrating to packfiles in the central repo.