Re: git fetch -v not at all verbose?

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 3, 2010, 16:14 UTC
Message-ID: <7vwrouxu42.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20101103095249.GA9144@redhat.com>

"Michael S. Tsirkin" <mst@redhat.com> writes:

Show 11 quoted lines

> On Thu, Jan 21, 2010 at 09:42:36AM -0800, Junio C Hamano wrote:
> ...
>> There was a discussion about updating the commit walk exchange to bisect
>> the history (skip and try a much older one to see if it is reachable, but
>> to avoid overshooting, step back and see if a newer one is still common).
>> It would be a lot more work and needs to be implemented as a new protocol
>> capability, but I think it is the right way to go in the longer term.
>
> I thought about this some more: it seems that nothing in
> pack-protocol.txt dictates that client has to send have
> lines in order. The whole logic would be on client side.

The current protocol may not require any order for it to function correctly in the sense that the sent pack will contain everything that is necessary, but it does require that commits on a lineage to be sent from near tip to near root if you want to have a _good_ common ancestor to be found.

If the downloader sends older commits first without sending some new ones, the uploader can say "Ok, I know about that old one you told me you have, so we could use that as a common commit" [*1*]. But there is no way for it to continue the sentence with "... but I cannot tell if other ones you told me you have that I know nothing about are all directly connected to that common one we just found (in which case that common one is the best we can do), or you have newer ones than the common commit that I also have but you omitted from the listing (in other words, if you didn't omit them, we could have found a better common commit). Could you please back up a bit and let us see if we can do better with newer ones?" with the current protocol exchange.

The downloader _could_, upon seeing an ACK to a commit that is an ancestor of commits that it skipped, try sending these skipped commits, without telling the uploader that it what it is doing. But the uploader will unilaterally decide when it thinks it has heard enough, after giving an ACK back in the original protocol, or after finding enough common ancestors to cover all the tips requested with WANTs, so I suspect that you may not have a chance to play such a game without an explicit protocol extension.

[Footnote]

*1* That is what an ACK means. In an multi-ack exchange, it also tells the downloader there is no point to give any ancestors of that commit, but allows the downloader to continue sending commits from other lineage.