On 11/9/20 2:56 PM, Jonathan Tan wrote: >> 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
