> 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. Thanks. > 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. Makes sense. The client already needs to opt-in by specifying the base, but yes, an option needs to be added for the server. > 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) Noted. > 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. I think the ability to send multiple bases would work in this scenario, but this might run into concerns that other reviewers have brought up (specifically, the fact that we're using environment variables and HTTP headers to pass this information - and among other things, line length limits). So a more comprehensive solution might be needed, even if only for this reason. > Looking forward to your next version. Thanks.
