On July 27, 2019 10:46:43 AM PDT, Junio C Hamano [off-list ref] wrote:

Christopher Head [off-list ref] writes:

Quite honestly, the true culprit of the above story is that you are
letting multiple logically different remote repositories [*1*] use
the same single remote-tracking refes/remotes/myremote/ hierarchy.

They weren’t supposed to be logically different (if I understand what you mean by that phrase). My intention was for the different URLs to be mirrors of each other, and multiple push URLs seemed to be the easiest way to update all the mirrors without having to mess around with making them trust each other and sending notifications and such.

If not this, then what are multiple push URLs on a single remote meant for?

If your previous "git push myremote" (with or without lease does not
matter, as this discussion is to illustrate that your setup is
fundamentally wrong) updated X but for some reason failed to update
Y (perhaps the network to Y was unreachable back then), and
refs/remotes/myremote/mybrach got updated to reflect the update to
X, what happens to your next "git push myremote" (or more
specifically, "git push Y")?  The repository on your local side
thinks that the other party has already took the previous push but
in reality that is the state of X, and Y hasn't seen that previous
push.

Of course it wouldn’t be perfect even with my proposed behaviour. It just seemed more useful than the existing behaviour, which will essentially *never* do anything useful as far as I can tell.

-- 
Christopher Head