Re: [RFC PATCH] push: perform negotiation before sending packfile

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 18, 2021, 01:34 UTC
Message-ID: <xmqqwnv6gnuq.fsf@gitster.g>
In-Reply-To: <20210218012100.928957-1-jonathantanmy@google.com>

Jonathan Tan <jonathantanmy@google.com> writes:

> The idea of adding negotiation to push has been floating around for a
> while. Here's my implementation of my idea of reusing a lot of the fetch
> mechanism to perform the negotiation.

Finally? Yay!

Show 9 quoted lines

> The basic idea is that when a client pushes, the client will first
> perform the negotiation steps that it normally does during a fetch,
> except that it does not send any "want"s and it only uses the commits to
> be pushed as negotiation tips (instead of all refs). Once the client has
> received enough ACKs that all ancestral paths from all tips to the
> original orphans are blocked by ACKed commits, it will proceed with the
> push, using this information to determine the contents of the
> to-be-pushed packfile. (This check is done by the server when doing a
> user-triggered fetch.)

So when pushing 'HEAD' to some ref, we say "I have HEAD^{commit}, HEAD^^, HEAD^^^, ..." and they keep saying "never heard of it" for each of them until they find "ah, I know that one" with an ACK, at which point we can stop traversing our side of the history behind that acked commit (because everything behind it is common between us). And that way, we know what we do not have to send (i.e. what we should use as the negative ends of "rev-list --objects A..B"; their ACK lets us discover "A").

Do we take advantage of the ref advertisement the other side perform, or is this v2 only and we even skip ls-refs?

What do you mean by an "orphan", though? Except for that part, I think what you wrote the above makes quite a lot of sense.

When we have an "--allow-unrelated-histories" merge with a history they've never heard of, we'd end up digging down to the root of the unrelated side history with "have/nack" exchange. On the fetch side, we have "give up with too many nack" band-aid. Do we inherit the same from the fetch side?

>  - Do we need statistics in the commit message to show the performance
>    gains?

Not until we see the thing fully working, I would say.

Show 5 quoted lines

>  - Anything else that comes up upon more scrutiny
>
> Any comments are welcome, especially if you have ideas about the overall
> design or implementation, and/or if you've thought about similar things
> before.

I'll have more comments after reading the code, but that will happen much later tonight.

Thanks.