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

[Junio C Hamano <gitster@pobox.com>]

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.