Re: Pushing vs. alternates

Junio C Hamano [off-list ref] writes:

quoted

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?