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

From: Jonathan Tan <jonathantanmy@google.com>
Date: Feb 18, 2021, 23:02 UTC
Message-ID: <20210218230248.1165266-1-jonathantanmy@google.com>
In-Reply-To: <xmqqwnv6gnuq.fsf@gitster.g>

Show 7 quoted lines

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

Thanks.

Show 18 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").

Yes, that's right.

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

My plan is to make it v2-only, but I don't think that there are technical limitations in adding it to v0. I'm planning to skip ls-refs (the current proof-of-concept code still calls ls-refs but doesn't use its results). If we need to take advantage of the ref advertisement, we could just use push's one.

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

By "orphan" I meant the commits that don't have any parents - so, the root commits.

Show 5 quoted lines

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

Yes. (But like fetch, this "in vain" check triggers only after the first ACK.)

> >  - Do we need statistics in the commit message to show the performance
> >    gains?
> 
> Not until we see the thing fully working, I would say.

OK.