Re: [PATCH 4/4] Doc: push with --base

From: Derrick Stolee <stolee@gmail.com>
Date: Nov 9, 2020, 21:00 UTC
Message-ID: <d72de441-e7f4-347d-e37a-e8e530855821@gmail.com>
In-Reply-To: <20201109195630.2511149-1-jonathantanmy@google.com>

On 11/9/20 2:56 PM, Jonathan Tan wrote:

Show 9 quoted lines

>> People expect that a single repository at their hosting sites can be
>> used as the central meeting point for the project, just like CVS/SVN
>> servers were in older world.  "git push" would need to accept that
>> reality and start common ancestor discovery eventually.
> 
> Thanks for your reply (and everyone else's). I was thinking that a more
> rudimentary form of the feature would suffice, since I wasn't expecting
> much more need in the future, but looks like this isn't the case. I'll
> be thinking of a more comprehensive idea.

I think this "half round negotiation" idea you have has merit, and can get us 95% of the benefit that a multi-round negotiation would bring without those extra steps.

My concerns with the current series is that it isn't fully ready for even that case. In my mind, a protocol change like this would need:

1. A top-to-bottom implementation that allows a user to opt-in to
   this new behavior with a config setting.

2. A demonstration of situations where this algorithm out-performs
   the existing algorithm (i.e. client is far behind server, but
   topic is a small change based on something in server's history)

3. A clear way to handle odd cases, such as multiple merge-bases.
   This leads to a change in how you are sending the data.

Perhaps this "send multiple OIDs in a payload" is already half-way to implementing a full negotiation, and we might as well go all the way in the writing. I expect that sending all maximal merge-bases will be sufficient for the vast majority of cases, and so any multi-round negotiation process will almost always end after the client sends that data.

Looking forward to your next version.

Thanks, -Stolee