Den ons 7 apr. 2021 kl 15:34 skrev Julian Foad <julianf...@apache.org>:
> > Ack, and thanks for picking up on this omission. Does that all stack up > now? > > I have committed it now, https://svn.apache.org/r1888474 , as I have just > got to the point of a complete implementation and tests. I am going to > nominate it for backport. > > That doesn't imply that I assume all your concerns are addressed. It can > still be questioned and changed. > A bit late to the party and I must confess I don't really understand all the implications but I've tried to follow the discussions best I can. I'm not too fond of the "relocate workaround" described in JIRA. I would have prefered to restore the behaviour of 1.6/1.7 which would solve case 1 and 2 but also change case 3 from inconvenience to "let's do a a same-repository-merge between repositories that are not equivalent". I can't judge the frequency of case 1/2 versus the frequency of case 3 and I can't judge impact of an incorrect merge in case 3. I suppose you have done the math and found that incorrect merges pose an unacceptable risk? Would it make sense to have a command line option to force a behaviour of 1.6/1.7? Then the error message could point at this option and users who have case 1/2 can take that option to perform the merge without the relocate workaround? Kind regards Daniel Sahlberg
