On Sat, Jul 27, 2019 at 09:54:40AM -0700, Christopher Head wrote:
> 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. ;)
