Re: Some issues when trying to set up a shallow git mirror server

From: Richard Maw <richard.maw@codethink.co.uk>
Date: Jan 13, 2016, 11:37 UTC
Message-ID: <20160113113743.GF3397@logi.codethink.co.uk>
In-Reply-To: <xmqqy4butzw8.fsf@gitster.mtv.corp.google.com>

On Tue, Jan 12, 2016 at 10:29:27AM -0800, Junio C Hamano wrote:

Show 14 quoted lines

> 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.