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

From: Jonathan Tan <jonathantanmy@google.com>
Date: Nov 9, 2020, 22:47 UTC
Message-ID: <20201109224732.2549561-1-jonathantanmy@google.com>
In-Reply-To: <xmqq8sbab52p.fsf@gitster.c.googlers.com>

Show 17 quoted lines

> Jonathan Tan <jonathantanmy@google.com> 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@coredump.intra.peff.net/