Re: Dose git-fetch need --reference option like git-clone?

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 11, 2007, 09:19 UTC
Message-ID: <7vfxzdgmvr.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20071111083840.GA17231@glandium.org>

Mike Hommey <mh@glandium.org> writes:

> It would probably be reasonable to have this on git-remote. Anyways, you
> can easily do it yourself by editing .git/objects/info/alternates and
> adding /path/to/remoteACloned in it. You can happily git fetch after
> that.

Not really.

There are two parts in the --reference dance git-clone plays:

 - After the reference clone is done, obviously because you are
   avoiding to actually transfer the data, you need to set up
   alternates to permanently borrow from the reference
   repository.

 - Because the fetch/clone procedure considers an object that is
   locally accessible (either it locally exists, or exists in an
   alternate object store) "complete" (meaning, there is no need
   to fetch the objects that are reachable from it) ONLY when it
   is reachable from one of the refs in the repository, the
   above alone would not prevent fetch/clone from actually
   transferring the objects.  For this reason, git-clone copies
   the refs that exist in the reference repository as temporary
   refs.  This ensures that the objects that the clone borrows
   from the reference repository are considered "complete"
   during the clone process.

The original design of git differenciated the object store (that is, .git/objects/) and a repository (.git). A repository has an object store associated with it, but the design allowed an object store to be shared among multiple repositories by symlinking. This is why alternates point at objects/ directory of the reference repository, not one level above.

Today, no git tool creates such a "shared object store" layout, so if the original design were "an object store belongs only to one repository, and the ../refs directory relative to it always is the only set of refs that defines the completeness of the objects within it. No sharing of object store across repositories using symlink is allowed", we could redefine the completeness rule to also follow the alternates and doing so would eliminate the need for the latter "temporary ref" trick git-clone plays. But until we officially declare that a set of old repositories that uses the "shared object store" layout are not supported (and give a reasonably migration path), we unfortunately cannot do so.