summaryrefslogtreecommitdiff
path: root/t/t6422-merge-rename-corner-cases.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-10-26merge tests: expect improved directory/file conflict handling in ortLibravatar Elijah Newren1-8/+22
merge-recursive.c is built on the idea of running unpack_trees() and then "doing minor touch-ups" to get the result. Unfortunately, unpack_trees() was run in an update-as-it-goes mode, leading merge-recursive.c to follow suit and end up with an immediate evaluation and fix-it-up-as-you-go design. Some things like directory/file conflicts are not well representable in the index data structure, and required special extra code to handle. But then when it was discovered that rename/delete conflicts could also be involved in directory/file conflicts, the special directory/file conflict handling code had to be copied to the rename/delete codepath. ...and then it had to be copied for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it still missed some. Further, when it was discovered that there were also file/submodule conflicts and submodule/directory conflicts, we needed to copy the special submodule handling code to all the special cases throughout the codebase. And then it was discovered that our handling of directory/file conflicts was suboptimal because it would create untracked files to store the contents of the conflicting file, which would not be cleaned up if someone were to run a 'git merge --abort' or 'git rebase --abort'. It was also difficult or scary to try to add or remove the index entries corresponding to these files given the directory/file conflict in the index. But changing merge-recursive.c to handle these correctly was a royal pain because there were so many sites in the code with similar but not identical code for handling directory/file/submodule conflicts that would all need to be updated. I have worked hard to push all directory/file/submodule conflict handling in merge-ort through a single codepath, and avoid creating untracked files for storing tracked content (it does record things at alternate paths, but makes sure they have higher-order stages in the index). Since updating merge-recursive is too much work and we don't want to destabilize it, instead update the testsuite to have different expectations for relevant directory/file/submodule conflict tests. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26t/: new helper for tests that pass with ort but fail with recursiveLibravatar Elijah Newren1-3/+4
There are a number of tests that the "recursive" backend does not handle correctly but which the redesign in "ort" will. Add a new helper in lib-merge.sh for selecting a different test expectation based on the setting of GIT_TEST_MERGE_ALGORITHM, and use it in various testcases to document which ones we expect to fail under recursive but pass under ort. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-10t642[23]: be more flexible for add/add conflicts involving pair renamesLibravatar Elijah Newren1-6/+12
Much like the last commit accepted 'add/add' and 'rename/add' interchangably, we also want to do the same for 'add/add' and 'rename/rename'. This also allows us to avoid the ambiguity in meaning with 'rename/rename' (is it two separate files renamed to the same location, or one file renamed on both sides but differently)? Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-10t6422, t6426: be more flexible for add/add conflicts involving renamesLibravatar Elijah Newren1-8/+13
merge-recursive treats an add/add conflict where one of the adds came from a rename as a separate 'rename/add' type of conflict. However, if there is not content conflict after the content merge(s), then the file is not considered to be conflicted. That suggests the conflict type is really just add/add. Other merge engines might choose to print messages to the console that just refer to these as add/add conflicts; accept both types of output. Note: it could help to notify users if the three-way content merge of the rename had content conflicts, because when we then go to two-way merge THAT with the conflicting add we can get nested conflict markers. merge-recursive, unfortunately, doesn't do that, but other merge engines could. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-10t6422: fix multiple errors with the mod6 test expectationsLibravatar Elijah Newren1-9/+10
This test had multiple issues causing it to fail for the wrong reason(s): * rename/rename(1to2) conflicts have always left the original source path present in the working directory and index (at stage 1). Thus, the triple rename/rename(1to2) should result in 9 unstaged files, not 6. * It messed up the three-way content merge for checking the results of merging for one of the renames, accidentally turning it into a two-way merge. * It got the contents of the base files it was using to compare against wrong, due to an off-by-one error, and overwrite-redirection ('>') instead of append-redirection ('>>'). * It used slightly too-long conflict markers * It didn't include filenames in the conflict marker hunks (granted, that was a shortcoming of the merge-recursive backend for rename/add and rename/rename(2to1) conflicts, but since it's test_expect_failure anyway we might as well make it expect our preferred behavior rather than some compromise that we can't yet reach anyway). Fix these issues so that a merge backend which correctly handles these kinds of nested conflicts will pass the test. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-10t6416, t6422: fix incorrect untracked file countLibravatar Elijah Newren1-2/+2
Apparently I don't know how to count untracked files, and since the tests in question were marked as test_expect_failure, no one ever noticed it until now. Correct the count, as these tests clearly create three untracked files ('out', 'err', and 'file_count'). (I believe this problem arose because earlier incarnations counted lines via a pipe to 'wc -l'. Reviewers asked that it be replaced by writing the output to a file and using test_line_count, but when the temporary output was added to a separate file, the count of untracked files should have increased.) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-10t6422: fix bad check against missing fileLibravatar Elijah Newren1-3/+3
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-10Collect merge-related tests to t64xxLibravatar Elijah Newren1-0/+1437
The tests for the merge machinery are spread over several places. Collect them into t64xx for simplicity. Some notes: t60[234]*.sh: Merge tests started in t602*, overgrew bisect and remote tracking tests in t6030, t6040, and t6041, and nearly overtook replace tests in t6050. This made picking out relevant tests that I wanted to run in a tighter loop slightly more annoying for years. t303*.sh: These started out as tests for the 'merge-recursive' toplevel command, but did not restrict to that and had lots of overlap with the underlying merge machinery. t7405, t7613: submodule-specific merge logic started out in submodule.c but was moved to merge-recursive.c in commit 18cfc08866 ("submodule.c: move submodule merging to merge-recursive.c", 2018-05-15). Since these tests are about the logic found in the merge machinery, moving these tests to be with the merge tests makes sense. t7607, t7609: Having tests spread all over the place makes it more likely that additional tests related to a certain piece of logic grow in all those other places. Much like t303*.sh, these two tests were about the underlying merge machinery rather than outer levels. Tests that were NOT moved: t76[01]*.sh: Other than the four tests mentioned above, the remaining tests in t76[01]*.sh are related to non-recursive merge strategies, parameter parsing, and other stuff associated with the highlevel builtin/merge.c rather than the recursive merge machinery. t3[45]*.sh: The rebase testcases in t34*.sh also test the merge logic pretty heavily; sometimes changes I make only trigger failures in the rebase tests. The rebase tests are already nicely coupled together, though, and I didn't want to mess that up. Similar comments apply for the cherry-pick tests in t35*.sh. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>