> Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > > >> 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 said "eventually", meaning that we may not have to solve it > immediately, but judging from the need for ad-hoc workarounds like > sending older commits that are not necessarily at the tip of > anything from the receiving end as if they are tips and then another > ad-hoc workaround like this one, it seems that the need is real. That's true. And if we need a more comprehensive solution than putting bases as Extra Parameters (and don't think that base-in-Extra-Parameter will form a part of that comprehensive solution), then I do think that we should go for the comprehensive solution instead of making something obsolete that we will still need to support later. > Would the earlier refactoring of the negotiation part into a > separate negotiator module help, or did the refactor not remove the > deep assumption that it is only about the fetch/upload-pack traffic > and we need a design for push/receive-pack from scratch? The negotiator module might help - looking that the API, it takes a list of known commons (none in this case, because we want to skip the long ref advertisement) and a list of tips to check (for this case, the tips we want to push), and then the negotiation starts. So we might be able to use it in a push v2. Having said that, it might be possible to reuse the existing fetch v0/v2 protocol to perform this negotiation (preferably v2, so that we can skip the ref advertisement). We'll just need to add the opposite of the "no-done" capability to make sure that the server never sends a packfile. Once we have found the base commit(s) either through push v2 or through fetch+opposite-of-no-done, we'll need to send the packfile somehow. My proposal here could do it, although then we might run into the problems Peff describes about Extra Parameters [1]. If we don't use Extra Parameters, we would probably need a push v2, but we might then run into similar problems to what we had during the fetch v2 migration (e.g. unexpected subtly different behaviors). [1] https://lore.kernel.org/git/20201103151859.GA444466@xxxxxxxxxxxxxxxxxxxxxxx/
