Re: Push force-with-lease with multi-URL remote

[Jeff King <peff@peff.net>]

On Mon, Jul 29, 2019 at 06:33:32AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > My general feeling is that having multiple push URLs for a remote is a
> > poorly designed feature in Git (and I think the discussion elsewhere in
> > this thread went there, as well).
> 
> That's being generous.  I do not think it was even designed---at
> least, the interaction with remote-tracking is ill thought out,
> but I think the updating of remote-tracking by pretending to have
> turned around and fetched immediately after it has done its thing
> came much later than multiple URLs for push.  A remote with multiple
> URLs without any remote-tracking (i.e. "push only remote") behaves
> semi-sensibly.

Yeah, the auto-update of the tracking refs came later (so I think you
could argue the bad interaction is my fault!).

> > But since we do have it, and if we are not going to deprecate it[1], it
> > seems like this case should pick the X value of myremote/mybranch ahead
> > of time, and then use it consistently for each push.
> 
> I agree but only if the listed ones are separate ones.  If the URLs
> are separate paths to reach the same remote (e.g. https:// and ssh://
> going to the same place), the current definition would make more sense.

Hmm, true. I'd almost argue that --force-with-lease, at least in its
default mode with no explicit lease source specified, should allow an
update from X to Y to be a successful noop if the remote "somehow"
already moved to Y.

This multi-URL push is one such "somehow", but I could imagine a case
where two other independent processes are racing. And we do not care at
all how we get to "Y", only that we get there.

But I haven't thought it through carefully, and I wonder if some users
would be unhappy not to find out that somebody had moved to "Y" already.

-Peff