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
test
Description: Binary data
