Re: 'git clone' doesn't use alternates automatically?

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

Jeff King <peff@peff.net> writes:

> The hardlink code operates by default because it was thought to be a
> safe optimization that couldn't bite people. But it interacts badly with
> the concept of alternates.

Yes, you are right.

To be fair, I think it was proposed/implemented by somebody who almost
never uses alternates himself, and certainly never a relative alternates.
The intention of hardlinking was while saving tons of disk space, still be
independent from the original repository.

Back when e95ab1e ([PATCH] Short-circuit git-clone-pack while cloning
locally (take 2)., 2005-07-06) was done, the packfile implementation was
still only a week old, and hardlinking made a lot of sense from space
saving's point of view.  These days, if you make a local hardlinked clone,
work a little there and then repack it, most of the space saving will be
gone; there isn't much point in the hardlink optimization anymore from
that angle, even though it still is a good compromise between the clone
speed and safety, especially when no alternates are involved.

I think a possible fix would be not to copy alternates file literally, but
install an alternates file to directly borrow from the same repositories
the clone-source repository borrows from ourselves, taking relative paths
into account.  Another would be to look at the alternates and hardlink the
objects and packs while cloning, and if the repositories involved reside
across filesystem boundaries, we need to fall back to copying.