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

From: Jeff King <peff@peff.net>
Date: Jul 29, 2019, 10:20 UTC
Message-ID: <20190729102009.GC2755@sigill.intra.peff.net>
In-Reply-To: <20190727095440.1aac3b3c@amdahl.home.chead.ca>

On Sat, Jul 27, 2019 at 09:54:40AM -0700, Christopher Head wrote:

Show 10 quoted lines

> For each URL:
> 1. Read refs/heads/mybranch (call this commit X)
> 2. Read refs/remotes/myremote/mybranch (call this commit Y)
> 3. Send to the URL an atomic compare-and-swap, replacing Y with X.
> 4. If step 3 succeeded, change refs/remotes/myremote/mybranch to X.
> 
> This means that, assuming both URLs start out identical, the second URL
> will always fail because refs/remots/myremote/mybranch has been updated
> from Y to X, and therefore the second compare-and-swap fails. I can’t
> imagine any situation in which this behaviour is actually useful.

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).

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. There are questions of partial push failures, etc, but as you note the current behavior isn't ever useful. I think it just a case where two features do not interact well (and since neither is used all that frequently, nobody has noticed).

-Peff

[1] I would not be at all sad to see multiple URLs like this get
    deprecated in favor of multiple remotes with convenient grouping
    options. If that happens, then your original problem goes away. ;)