[PATCH 0/3] Add missing rename-related corner cases for merging

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@mail.gmail.com/

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(+)