Re: warning: no common commits - slow pull

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

Daniel Barkalow <barkalow@iabervon.org> writes:

> Correcting the transport code is important (and should probably be done in 
> transport.c, if possible), but I think we're being a bit silly in 
> autofollowing tags anyway. If we decide to fetch T due to having T^{}, we 
> should tell the remote up front that we have T^{}, before we mention 
> anything else, because it's obviously true and it's also absolutely 
> certain to make the remote immediately do the right thing.

That's correct, and the autofollowing code does so.  You will
not know if you have T^{} until your primary transfer finishes,
so you cannot roll autofollow into it.

I think we can teach the upload-pack side to be more helpful and
with a protocol extension to send tag objects that are pointing
at commits that will be included in the result, or something
like that, though.  But that is outside the scope of 1.5.5; it
would be a moderate to large protocol surgery, and I suspect it
might even have to affect pack-objects.

> It's silly to 
> decide to fetch T because we will only need that one object, and then not 
> instantly tell the server we only need that one object. (And, as luck 
> would have it, yesterday I wrote code to cause for_each_ref return some
> specific values in addition to and before the actual stored refs.)

You won't know if you need only one object, so seeing that you
have T^{} and asking _only_ for T is _wrong_.  Think of a tag
that points at another tag that points at the commit.  You need
to tell the other end "I have T^{}, please give me T", and that
is exactly what the autofollowing does.