Jeff King <peff@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
