In merging, every rename acts as a two-piece lego in terms of conflicts. We have long realized that the other branch can (1) delete the source side of a rename, giving a rename/delete conflict, or (2) add a file in the way of the rename destination, giving a rename/add conflict, or (3) have a rename of its own touching either the same destination or source path, giving either a rename/rename(2to1) or rename/rename(1to2) conflict. But only in one case did we ever consider chaining these merge-conflict lego pieces (namely with rename/rename(1to2)/add/add conflicts). Add some testcases that show other ways these conflicts can be chained. In short, any rename's source side can attach to a delete or another rename, and any rename's destination side can attach to an add or another rename. This series was spurred by Robert Dailey's report back in March of a rename case that git currently handles poorly: https://public-inbox.org/git/CAHd499Axo7HFviUJavigTZ6BGZCkj9iOSeNVndu1oPivkPv+5Q@xxxxxxxxxxxxxx/ This series adds a testcase covering the issue he reported, and then rounds things out additional testcases demonstrating other ways rename conflicts could be "chained" together. Elijah Newren (3): t6042: add testcase covering rename/add/delete conflict type t6042: add testcase covering rename/rename(2to1)/delete/delete conflict t6042: add testcase covering long chains of rename conflicts t/t6042-merge-rename-corner-cases.sh | 245 +++++++++++++++++++++++++++ 1 file changed, 245 insertions(+) -- 2.18.0.130.gd703bbb5d
