Web lists-archives.com

[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@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