> Jonathan Tan <jonathantanmy@xxxxxxxxxx> 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.
> > 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.
> 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.
