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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 12, 2016, 18:29 UTC
Message-ID: <xmqqy4butzw8.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160111155153.GE3397@logi.codethink.co.uk>

Richard Maw <richard.maw@codethink.co.uk> writes:

Show 24 quoted lines

> On Fri, Jan 08, 2016 at 01:37:02PM -0800, Junio C Hamano wrote:
> ...
>> So if you want to do this, a new protocol extension needs to allow
>> your updated sender (upload-pack) and receiver (fetch-pack) to work
>> more like this:
>> ...
>>  * Finally, when the sender sends out the resulting packfile, it
>>    also has to tell the receiver which of the object pairs the
>>    receiver asked it to check the ancestry relationship violate the
>>    fast-forward rule.  In the earlier example of fast-forwarding O
>>    and P with N, where the receiver asked "want N O P", the receiver
>>    asked to check object pairs <N, O> and <N, P>.  If P fast-forwards
>>    to N but O does not, then the sender would tell the receiver the
>>    fact that "O does not fast forward to N".
>
> So this would be another step after the receiver communicates "done",
> but before the pack file itself gets sent,
> so the sender can determine that it doesn't need to tell the reciever
> the relationship between two commits,
> since it knows you can work it out yourself?
>
> Otherwise if it can probably communicate the relationships before the have list
> is sent, and extend the shallow-update part of the protocol instead, which
> might be simpler.

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.

Show 14 quoted lines

>> With such an extension, your updated receiver can receive the
>> necessary objects to update your history to "N", but notice that it
>> would result in non-ff update to update master (that used to be O)
>> with the new commit N.
>
> Code-wise, does the following make sense?
>
> 1.  Add a field to `struct ref` to flag a "trusted fast-forward".
> 2.  Change `find_common()` in `fetch-pack.c`
>     and `receive_needs()` in `upload-pack.c`
>     to communicate the relationships we're interested in as above,
>     and set the "trusted fast-forward" flag.
> 3.  Change `update_local_ref()` in `builtin/fetch.c`
>     to check `ref->trusted_fast_forward || in_merge_bases(current, updated)`.