On Tue, Jan 12, 2016 at 10:29:27AM -0800, Junio C Hamano wrote:
> I left the detail as vague ;-).
>
> The new request does not have to piggyback on existing "want"
> message. And thinking about it again, it probably is cleaner if it
> didn't. After the use of the protocol extension "ancestry-check" is
> negotiated the usual way between the sender and the receiver, the
> receiver would send "check-ff N O" and "check-ff N P" after it sends
> all of its "want" messages but before it sends the "flush" to go
> into the "have"/"ack" common ancestry discovery.
>
> I do not have a strong opinion on where the sender should reply with
> "not-ff N O" in the protocol. Immediately after the receiver says
> "I've done with my 'want's (and now 'check-ff's)" by flushing may be
> a good place to do so.
In that case, I can think of two other useful times to do it:
1. Before any "want" requests.
This would also let you extend ls-remote to let it display ancestry.
This is complicated by the fact that normally the client responds
with which features it supports in the first "want",
so the sender would have to support "check-ff N O <FEATURES>"
if it advertised "ancestry-check".
2. After the pack is transferred.
Then the receiver can check ancestry with the objects,
and only request ancestry if it's missing history.
I'm not sure whether there's any value in not requesting it,
since while it would reduce the amount of work the sender needs to do,
it still means the sender has to wait for the client to do the check,
rather than hanging up and allowing it to process another connection.
--
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