Junio C Hamano <gitster@xxxxxxxxx> writes: > - With this approach, we can cut down the initial ref advertisement > from the receiving end to the minimum. The protocol with > negotiation could work correctly without receiving end > advertising no refs, but I suspect that it would be very common > in a publishing repository (not a shared everybody-pushes-into > repository) that the tip of the target repository is known by the > pusher, and it may help such a case to know where the ref being > updated with this push originally points at. But even in such a > case, additional negotiation may help---the target branch may > have not advanced, but may of the side branches the pusher have > merged into the commit being pushed to the target branch may > already be known by the receiver. Addendum. The original push protocol where the pusher learns all the tips of refs the receiver has cuts down the resulting packdata transfer in such a "side branches already known by the receiver, only the fact that they were merged to the target branch is new" case. The pain only starts happening when we try to reduce the advertisement made by the receiver. As the "negotiation" is more targetted for the ref that actually is being pushed (as opposed to the blanket "here is everything I have" that can get unreasonably big), I think the idea to introduce the same common ancestor discovery that happens on the "fetch" side, and to share the code with the "fetch" side that has been battle tested, is a great one.
