summaryrefslogtreecommitdiff
path: root/t/t6036-recursive-corner-cases.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-05-17Merge branch 'jc/ll-merge-internal'Libravatar Junio C Hamano1-84/+2
"git rerere" can get confused by conflict markers deliberately left by the inner merge step, because they are indistinguishable from the real conflict markers left by the outermost merge which are what the end user and "rerere" need to look at. This was fixed by making the conflict markers left by the inner merges a bit longer. * jc/ll-merge-internal: t6036: remove pointless test that expects failure ll-merge: use a longer conflict marker for internal merge ll-merge: fix typo in comment
2016-05-09t6036: remove pointless test that expects failureLibravatar Junio C Hamano1-83/+0
One test in t6036 prepares a file whose contents contain these lines: <<<<<<< Temporary merge branch 1 C ======= B >>>>>>> Temporary merge branch 2 and uses recursive merge strategy to run criss-cross merge with it. Manual merge resolution by users fundamentally depends on being able to distinguish the tracked contents from the separator lines added by "git merge" in order to allow users to tell which block of lines came from where. You can deliberately craft a file with lines that resemble conflict marker lines to make it impossible for the user (the outer merge of merge-recursive counts as a user of the result of "virtual parent" merge) to tell which part is which, and write a test to demonstrate that with such a file that "git merge" cannot fundamentally work well and has to fail. It however is pointless and waste of time and resource to run such a test that asserts the obvious. In real life, people who do need to track files with such lines that have <<<< ==== >>>> as their prefixes set the conflict-marker-size attribute to make sure they will be able to tell between the tracked lines that happen to begin with these (confusing) prefixes and the marker lines that are added by "git merge". Remove the test as pointless waste of resource. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-09ll-merge: use a longer conflict marker for internal mergeLibravatar Junio C Hamano1-1/+2
The primary use of conflict markers is to help the user who resolves the final (outer) merge by hand to show which part came from which branch by separating the blocks of lines apart. When the conflicted parts from a "virtual ancestor" merge created by merge-recursive remains in the common ancestor part in the final result, however, the conflict markers that are the same size as the final merge become harder to see. Increase the conflict marker size slightly for these inner merges so that the markers from the final merge and cruft from internal merge can be distinguished more easily. This would help reduce the common issue that prevents "rerere" from being used on a really complex conflict. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: use test_must_fail instead of hand-rolled blocksLibravatar Jeff King1-6/+1
These test scripts likely predate test_must_fail, and can be made simpler by using it (in addition to making them pass --chain-lint). The case in t6036 loses some verbosity in the failure case, but it is so tied to a specific failure mode that it is not worth keeping around (and the outcome of the test is not affected at all). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix severe &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, in a location which causes a significant portion of the test to be missed (e.g., the test effectively does nothing, or consists of a long string of actions and output comparisons, and we throw away the exit code of at least one part of the string). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31code and test: fix misuses of "nor"Libravatar Justin Lebar1-1/+1
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix virtual merge base for rename/rename(1to2)/add-destLibravatar Elijah Newren1-1/+1
Earlier in this series, the patch "merge-recursive: add handling for rename/rename/add-dest/add-dest" added code to handle the rename on each side of history also being involved in a rename/add conflict, but only did so in the non-recursive case. Add code for the recursive case, ensuring that the "added" files are not simply deleted. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6036: criss-cross + rename/rename(1to2)/add-dest + simple modifyLibravatar Elijah Newren1-0/+69
This is another testcase trying to exercise the virtual merge base creation in the rename/rename(1to2) code. A testcase is added that we should be able to merge cleanly, but which requires a virtual merge base to be created that correctly handles rename/add-dest conflicts within the rename/rename(1to2) testcase handling. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Consider modifications in rename/rename(2to1) conflictsLibravatar Elijah Newren1-28/+10
Our previous conflict resolution for renaming two different files to the same name ignored the fact that each of those files may have modifications from both sides of history to consider. We need to do a three-way merge for each of those files, and then handle the conflict of both sets of merged contents trying to be recorded with the same name. It is important to note that this changes our strategy in the recursive case. After doing a three-way content merge of each of the files involved, we still are faced with the fact that we are trying to put both of the results (including conflict markers) into the same path. We could do another two-way merge, but I think that becomes confusing. Also, taking a hint from the modify/delete and rename/delete cases we handled earlier, a more useful "common ground" would be to keep the three-way content merge but record it with the original filename. The renames can still be detected, we just allow it to be done in the o->call_depth=0 case. This seems to result in simpler & easier to understand merge conflicts as well, as evidenced by some of the changes needed in our testsuite in t6036. (However, it should be noted that this change will cause problems those renames also occur along with a file being added whose name matches the source of the rename. Since git currently cannot detect rename/add-source situations, though, this codepath is not currently used for those cases anyway. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix rename/rename(1to2) resolution for virtual merge baseLibravatar Elijah Newren1-1/+1
When renaming one file to two files, we really should be doing a content merge. Also, in the recursive case, undoing the renames and recording the merged file in the index with the source of the rename (while deleting both destinations) allows the renames to be re-detected in the non-recursive merge and will result in fewer spurious conflicts. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix modify/delete resolution in the recursive caseLibravatar Elijah Newren1-2/+2
When o->call_depth>0 and we have conflicts, we try to find "middle ground" when creating the virtual merge base. In the case of content conflicts, this can be done by doing a three-way content merge and using the result. In all parts where the three-way content merge is clean, it is the correct middle ground, and in parts where it conflicts there is no middle ground but the conflict markers provide a good compromise since they are unlikely to accidentally match any further changes. In the case of a modify/delete conflict, we cannot do the same thing. Accepting either endpoint as the resolution for the virtual merge base runs the risk that when handling the non-recursive case we will silently accept one person's resolution over another without flagging a conflict. In this case, the closest "middle ground" we have is actually the merge base of the candidate merge bases. (We could alternatively attempt a three way content merge using an empty file in place of the deleted file, but that seems to be more work than necessary.) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Make dead code for rename/rename(2to1) conflicts undeadLibravatar Elijah Newren1-8/+9
The code for rename_rename_2to1 conflicts (two files both being renamed to the same filename) was dead since the rename/add path was always being independently triggered for each of the renames instead. Further, reviving the dead code showed that it was inherently buggy and would always segfault -- among a few other bugs. Move the else-if branch for the rename/rename block before the rename/add block to make sure it is checked first, and fix up the rename/rename(2to1) code segments to make it handle most cases. Work is still needed to handle higher dimensional corner cases such as rename/rename/modify/modify issues. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Allow make_room_for_path() to remove D/F entriesLibravatar Elijah Newren1-1/+1
If there were several files conflicting below a directory corresponding to a D/F conflict, and the file of that D/F conflict is in the way, we want it to be removed. Since files of D/F conflicts are handled last, they can be reinstated later and possibly with a new unique name. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix recursive case with D/F conflict via add/add conflictLibravatar Elijah Newren1-2/+2
When a D/F conflict is introduced via an add/add conflict, when o->call_depth > 0 we need to ensure that the higher stage entry from the base stage is removed. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6036: criss-cross + rename/rename(1to2)/add-source + modify/modifyLibravatar Elijah Newren1-0/+77
This is another challenging testcase trying to exercise the virtual merge base creation in the rename/rename(1to2) code. A testcase is added that we should be able to merge cleanly, but which requires a virtual merge base to be created that is aware of rename/rename(1to2)/add-source conflicts and can handle those. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modifyLibravatar Elijah Newren1-0/+88
This test is mostly just designed for testing optimality of the virtual merge base in the event of a rename/rename(1to2) conflict. The current choice for resolving this in git seems somewhat confusing and suboptimal. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6036: tests for criss-cross merges with various directory/file conflictsLibravatar Elijah Newren1-0/+159
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6036: criss-cross with weird content can fool git into clean mergeLibravatar Elijah Newren1-0/+83
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6036: Add differently resolved modify/delete conflict in criss-cross testLibravatar Elijah Newren1-0/+83
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6042: Add a testcase where git deletes an untracked fileLibravatar Elijah Newren1-1/+1
Current git will nuke an untracked file during a rename/delete conflict if (a) there is an untracked file whose name matches the source of a rename and (b) the merge is done in a certain direction. Add a simple testcase demonstrating this bug. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-29Merge branch 'en/merge-recursive'Libravatar Junio C Hamano1-3/+182
* en/merge-recursive: (41 commits) t6022: Use -eq not = to test output of wc -l merge-recursive:make_room_for_directories - work around dumb compilers merge-recursive: Remove redundant path clearing for D/F conflicts merge-recursive: Make room for directories in D/F conflicts handle_delete_modify(): Check whether D/F conflicts are still present merge_content(): Check whether D/F conflicts are still present conflict_rename_rename_1to2(): Fix checks for presence of D/F conflicts conflict_rename_delete(): Check whether D/F conflicts are still present merge-recursive: Delay modify/delete conflicts if D/F conflict present merge-recursive: Delay content merging for renames merge-recursive: Delay handling of rename/delete conflicts merge-recursive: Move handling of double rename of one file to other file merge-recursive: Move handling of double rename of one file to two merge-recursive: Avoid doubly merging rename/add conflict contents merge-recursive: Update merge_content() call signature merge-recursive: Update conflict_rename_rename_1to2() call signature merge-recursive: Structure process_df_entry() to handle more cases merge-recursive: Have process_entry() skip D/F or rename entries merge-recursive: New function to assist resolving renames in-core only merge-recursive: New data structures for deferring of D/F conflicts ... Conflicts: t/t6020-merge-df.sh t/t6036-recursive-corner-cases.sh
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-1/+1
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29merge-recursive: Avoid doubly merging rename/add conflict contentsLibravatar Elijah Newren1-2/+2
When a commit moves A to B while another commit created B (or moved C to B), and these two different commits serve as different merge-bases for a later merge, c94736a (merge-recursive: don't segfault while handling rename clashes 2009-07-30) added some special code to avoid segfaults. Since that commit, the two versions of B are merged in place (which could be potentially conflicting) and the intermediate result is used as the virtual ancestor. However, right before this special merge, try_merge was turned on, meaning that process_renames() would try an alternative merge that ignores the 'add' part of the conflict, and, if the merge is clean, store that as the new virtual ancestor. This could cause incorrect merging of criss-cross merges; it would typically result in just recording a slightly confusing merge base, but in some cases it could cause silent acceptance of one side of a merge as the final resolution when a conflict should have been flagged. When we do a special merge for such a rename/add conflict between merge-bases, turn try_merge off to avoid an inappropriate second merge. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29t6036: Add testcase for undetected conflictLibravatar Elijah Newren1-0/+85
If merging two lines of development involves a rename/add conflict, and two different people make such a merge but resolve it differently, and then someone tries to merge the resulting two merges, then they should clearly get a conflict due to the different resolutions from the previous developers. However, in some such cases the conflict would not be detected and git would silently accept one of the two versions being merged as the final merge resolution. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29t6036: Add a second testcase similar to the first but with content changesLibravatar Elijah Newren1-0/+76
c94736a (merge-recursive: don't segfault while handling rename clashes 2009-07-30) added t6036 with a testcase that involved dual renames and a criss-cross merge. Add a test that is nearly identical, but which also involves content modification -- a case git currently does not merge correctly. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29t6036: Test index and worktree state, not just that merge failsLibravatar Elijah Newren1-3/+21
c94736a (merge-recursive: don't segfault while handling rename clashes 2009-07-30) added this testcase with an interesting corner case test, which previously had cased git to segfault. This test ensures that the segfault does not return and that the merge correctly fails; just add some checks that verify the state of the index and worktree after the merge are correct. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-30merge-recursive: don't segfault while handling rename clashesLibravatar Junio C Hamano1-0/+55
When a branch moves A to B while the other branch created B (or moved C to B), the code tried to rename one of them to B~something to preserve both versions, and failed to register temporary resolution for the original path B at stage#0 during virtual ancestor computation. This left the index in unmerged state and caused a segfault. A better solution is to merge these two versions of B's in place and use the (potentially conflicting) result as the intermediate merge result in the virtual ancestor. Signed-off-by: Junio C Hamano <gitster@pobox.com>