On Mon, Jul 29, 2019 at 06:33:32AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > My general feeling is that having multiple push URLs for a remote is a > > poorly designed feature in Git (and I think the discussion elsewhere in > > this thread went there, as well). > > That's being generous. I do not think it was even designed---at > least, the interaction with remote-tracking is ill thought out, > but I think the updating of remote-tracking by pretending to have > turned around and fetched immediately after it has done its thing > came much later than multiple URLs for push. A remote with multiple > URLs without any remote-tracking (i.e. "push only remote") behaves > semi-sensibly. Yeah, the auto-update of the tracking refs came later (so I think you could argue the bad interaction is my fault!). > > But since we do have it, and if we are not going to deprecate it[1], it > > seems like this case should pick the X value of myremote/mybranch ahead > > of time, and then use it consistently for each push. > > I agree but only if the listed ones are separate ones. If the URLs > are separate paths to reach the same remote (e.g. https:// and ssh:// > going to the same place), the current definition would make more sense. Hmm, true. I'd almost argue that --force-with-lease, at least in its default mode with no explicit lease source specified, should allow an update from X to Y to be a successful noop if the remote "somehow" already moved to Y. This multi-URL push is one such "somehow", but I could imagine a case where two other independent processes are racing. And we do not care at all how we get to "Y", only that we get there. But I haven't thought it through carefully, and I wonder if some users would be unhappy not to find out that somebody had moved to "Y" already. -Peff
