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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 14, 2011, 10:24 UTC
Message-ID: <7vmxbzj927.fsf@alter.siamese.dyndns.org>
In-Reply-To: <buomxbzutjm.fsf@dhlpc061.dev.necel.com>

Miles Bader <miles@gnu.org> writes:

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

With the alternate mechanism, your borrowing is read-only and that is exactly why you can borrow from other peoples' repositories to which you have no write permission to.

What you are suggesting is fundamentally different from the alternates mechanism. I am not saying it is better or worse, though. Not yet at this point in this message.

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

If you write objects to the central store, "gc" in the "clients" will be a no-op because they do not have their own objects. But instead, crufts your "clients" accumulate will be in the central store. There is still need for "gc" at the central store to remove things that are no longer used by any client, isn't it? Unless you declare that you do not care because perhaps the central store is large enough, that is.

At least with the alternates, running "gc" in the "clients" is a safe operation and the only change necessary is to make fsck/repack aware of the repositories that borrow from the repository these commands are run, and the logic to do so is exactly the same as the case to run "gc" in your central store, I would think.