Daniel Shahaf wrote: > The write-up doesn't seem to consider the possibility of issuing > a warning rather than a fatal error. This would negate the "does not > introduce a silent behavioural change" argument and not constitute > a flag day to anyone who may be "intentionally or unintentionally relying > on the current behaviour". Thoughts?
Good question. TL;DR: The behaviour is a bug not a feature. The case in question is where someone is running a merge with differing source and target (repository-root) URLs, and getting the "foreign repository" kind of merge result, but their "foreign repository" has the same UUID. The UUIDs indicate these URLs point to logically the same repository and so a "foreign repository" merge is the wrong behaviour. If a user in this situation is getting results that "work" for them it is only by accident. This is an exceptional case that we reasonably assume to be rare. If we warn instead of error in this exceptional case, then in this case it would continue to perform the "foreign repository" merge. While that may be convenient for anyone currently using this scenario (they would not have to change anything), it also has Bad properties: supporting misleading assumptions about how other variations of the scenario might behave. But the convenience is only useful for users in this exceptional case, whereas the negatives are there waiting for everybody who may some day be caught out when they use a different variant of their URL. In other words, continuing to support the current behaviour is a bug. When filing the issue I couldn't quite decide whether it was a bug or an enhancement (and started filing it as a bug at first, then finally filed it as an enhancement), but after thinking through all this I conclude it's a bug (and I've just changed the issue type to reflect that). -- - Julian
