Re: warning: no common commits - slow pull

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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.

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux