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