Re: Push force-with-lease with multi-URL remote

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 27, 2019, 17:46 UTC
Message-ID: <xmqqzhkzl69o.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190727095440.1aac3b3c@amdahl.home.chead.ca>

Christopher Head <bugs@chead.ca> writes:

Show 10 quoted lines

> 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....
> 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.

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.

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.