Junio C Hamano <junkio@xxxxxxx> writes: >> Well, I would send haves for the alternate repository anyway,... > > While I agree it would be an optimization if it worked, there is > one conceptual problem here though, coming from old warts. It's > not alternate "repository" but it is alternate object store. > There is no guarantee that refs/ directory that is next to the > objects/ alternate points at is related to that object store, > for historical reasons (i.e. we have separate GIT_DIR and > GIT_OBJECT_DIRECTORIES). Having said that, I am not opposed to the idea of using refs/ next to objects/ your alternate points at. Certainly I would not have any objection (heck I would even volunteer to code it myself if only to see how much we can save) if we did not have GIT_OBJECT_DIRECTORY in the system (i.e. if we had a guarantee from the beginning that objects/ directory that is next to refs/ *must* be related). So I am Ok with this change, but I would feel better if we add a few sentences to repository-layout.txt that warns about the (technically new although it is very likely that violating it would not have been useful at all) restriction. I suspect we could do the same for fetching in principle, e.g. when you track Linus's and a subsystem maintainer's trees and these two repositories are linked with alternates at your end. Fetching into your copy of Linus's and then fetching into your copy of subsystem would be optimized the same way if you send refs/ from the alternates as HAVEs, right? - 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