On July 27, 2019 10:46:43 AM PDT, Junio C Hamano <gitster@xxxxxxxxx> wrote: >Christopher Head <bugs@xxxxxxxx> 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
