Hi folks,
When a single remote has multiple push URLs, Git’s force-with-lease
logic appears to be:

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.

This is what I would expect:

1. Read refs/heads/mybranch (call this commit X)
2. Read refs/remotes/myremote/mybranch (call this commit Y)
3. For each URL:
3a. Send to the URL an atomic compare-and-swap, replacing Y with X.
4. If any (or maybe all) of the CAS operations in 3a succeeded, change
refs/remotes/myremote/mybranch to X.

Thoughts? Does anyone have a use case for the existing behaviour? I
have attached a shell script which constructs some repos and
demonstrates the situation.

Thanks!
-- 
Christopher Head