Re: git fetch -v not at all verbose?

"Michael S. Tsirkin" [off-list ref] writes:

On Thu, Jan 21, 2010 at 09:42:36AM -0800, Junio C Hamano wrote:
...

quoted

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.