On Mon, Feb 02, 2009 at 08:30:36PM -0800, Junio C Hamano wrote: > 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 Well, in your defense, relative alternates didn't come about until two months later, in ccfd3e9. So you can blame the author of that patch for screwing up your existing work. :) > 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. True. But I still think the hardlinks are nice for one-off repositories. Every once in a while I want to start a new topic or experiment while my repository is a mess; it's nice to just "git clone git foo", hack around in the work directory, and blow it away. And the hardlinks make that first step a _lot_ faster. But I also don't mind having to add a command-line option to get the speed. And for my use case, there really isn't a benefit to hardlinks over alternates. > 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. Yes, either of those would work. But I wonder if it is really worth the complexity. When I suggested just ditching hardlinks if the remote uses alternates, my thought was that most people won't really care. Either they use alternates, in which case they should be providing "-s" and not doing hardlinks, or they don't, in which case things will happen as usual. But reading your response, I wonder if it is worth keeping the hardlink optimization around at all; getting rid of it would simplify the code and the explanation of why "git clone foo" is different from "git clone file://$PWD/foo". If people want a fast, dependent clone, they can use "-s". I guess hardlinks are also useful for a fast "git clone foo bar; rm -rf foo". But I'm not sure how common that is. -Peff -- 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
