Re: warning: no common commits - slow pull
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 27, 2008, 20:53 UTC
- Message-ID
- <7vskzeruit.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <alpine.LNX.1.00.0802271411280.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
Show 6 quoted lines
> 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.
Show 5 quoted lines
> 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.