Daniel Shahaf wrote: > Julian Foad wrote: > > If we warn [...] it also has Bad properties: > > supporting misleading assumptions about how other variations of the > > scenario might behave. > > Could you be more concrete about those assumptions?
It's not the warning itself but that continuing to behave illogically would support bad assumptions. One example: if the user is accustomed to the foreign-repo merge behaviour (despite same UUIDs) using a script that says (x = repository root URL path) source1=http://x source2=https://x target=https://x then they might assume that "correcting" source1 in their script to say source1=https://x source2=https://x target=https://x would keep the same behaviour; but it doesn't. Of course a warning could try to explain sufficiently but the current behaviour is not self-consistent enough to explain in one short sentence. > The negatives that would be waiting in a hypothetical release that > issues warnings as proposed aren't that bad, and certainly not as bad > as those in the current release, are they? Not as bad as the current release, of course. > [...] we can phrase the > warning clearly enough that anyone who runs into it unintentionally will > abort the merge and re-do it "correctly", without us needing to enforce > it by issueing a fatal error. [...] > I don't disagree with classifying this as a bug, but I still don't > understand why issueing a warning wouldn't be satisfactory — or, at > least, have 1.15 issue a warning and 1.16 upgrade that to a fatal error, > just to be on the safe side. See the example output above, line 4. That's a good strategy for dealing with cases in general where a behaviour one "supported" in practice needs to be withdrawn. If this were an issue in a more main-stream merge case, I would agree. However, the proposed benefit that we offer by continuing the merge is targetting the wrong group: it is a supposed convenience to users whose UUIDs are misconfigured, while it would be a hindrance to users who run into it by accident while having their UUIDs correctly configured. Also, this is so much an edge case that it isn't worth the extra complexity on our side; we don't have a great track record of getting around to doing things that we scheduled for a later release, for instance. Handling it so gently for the affected users is a nicety that doesn't feel worth it. I think the reasonable use cases for the case in question and the likely number of occurrences in practice are both near zero. I don't have numbers to back up this feeling, but as far as I am aware nobody has reported this issue and it has existed for many years. > By the way, I don't feel strongly about this matter; it simply happens > to be the one place in the write-up of the issue where I couldn't see > why an alternative design was ruled out. Ack, and thanks for picking up on this omission. Does that all stack up now? -- - Julian
