summaryrefslogtreecommitdiff
path: root/t/t6036-recursive-corner-cases.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-12-01t6036: avoid non-portable "cp -a"Libravatar Carlo Marcelo Arenas Belón1-1/+1
b8cd1bb713 ("t6036, t6043: increase code coverage for file collision handling", 2018-11-07) uses this GNU extension that is not available in a POSIX complaint cp. In this particular case, there is no need to use the option, as it is just copying a single file to create another file. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-08t6036, t6043: increase code coverage for file collision handlingLibravatar Elijah Newren1-0/+51
Stolee's coverage reports found a few code blocks for file collision conflicts that had not previously been covered by testcases; add a few more testcases to cover those too. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-08merge-recursive: improve handling for rename/rename(2to1) conflictsLibravatar Elijah Newren1-9/+3
This makes the rename/rename(2to1) conflicts use the new handle_file_collision() function. Since that function was based originally on the rename/rename(2to1) handling code, the main differences here are in what was added. In particular: * Instead of storing files at collide_path~HEAD and collide_path~MERGE, the files are two-way merged and recorded at collide_path. * Instead of recording the version of the renamed file that existed on the renamed side in the index (thus ignoring any changes that were made to the file on the side of history without the rename), we do a three-way content merge on the renamed path, then store that at either stage 2 or stage 3. * Note that since the content merge for each rename may have conflicts, and then we have to merge the two renamed files, we can end up with nested conflict markers. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-08merge-recursive: fix rename/add conflict handlingLibravatar Elijah Newren1-11/+13
This makes the rename/add conflict handling make use of the new handle_file_collision() function, which fixes several bugs and improves things for the rename/add case significantly. Previously, rename/add would: * Not leave any higher order stage entries in the index, making it appear as if there were no conflict. * Would place the rename file at the colliding path, and move the added file elsewhere, which combined with the lack of higher order stage entries felt really odd. It's not clear to me why the rename should take precedence over the add; if one should be moved out of the way, they both probably should. * In the recursive case, it would do a two way merge of the added file and the version of the renamed file on the renamed side, completely excluding modifications to the renamed file on the unrenamed side of history. Use the new handle_file_collision() to fix all of these issues. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-08merge-recursive: increase marker length with depth of recursionLibravatar Elijah Newren1-0/+151
Later patches in this series will modify file collision conflict handling (e.g. from rename/add and rename/rename(2to1) conflicts) so that multiply nested conflict markers can arise even before considering conflicts in the virtual merge base. Including the virtual merge base will provide a way to get triply (or higher) nested conflict markers. This new way to get nested conflict markers will force the need for a more general mechanism to extend the length of conflict markers in order to differentiate between different nestings. Along with this change to conflict marker length handling, we want to make sure that we don't regress handling for other types of conflicts with nested conflict markers. Add a more involved testcase using merge.conflictstyle=diff3, where not only does the virtual merge base contain conflicts, but its virtual merge base does as well (i.e. a case with triply nested conflict markers). While there are multiple reasonable ways to handle nested conflict markers in the virtual merge base for this type of situation, the easiest approach that dovetails well with the new needs for the file collision conflict handling is to require that the length of the conflict markers increase with each subsequent nesting. Subsequent patches which change the rename/add and rename/rename(2to1) conflict handling will modify the extra_marker_size flag appropriately for their new needs. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-08t6036, t6042: testcases for rename collision of already conflicting filesLibravatar Elijah Newren1-0/+194
When a single file is renamed, it can also be modified, yielding the possibility of that renamed file having content conflicts. If two different such files are renamed into the same location, then two-way merging those files may result in nested conflicts. Add a testcase that makes sure we get this case correct, and uses different lengths of conflict markers to differentiate between the different nestings. Also add another case with an extra (i.e. third) level of conflict markers due to using merge.conflictstyle=diff3 and the virtual merge base also having conflicts present. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-18merge-recursive: avoid showing conflicts with merge branch before HEADLibravatar Elijah Newren1-4/+4
We want to load unmerged entries from HEAD into the index at stage 2 and from MERGE_HEAD into stage 3. Similarly, folks expect merge conflicts to look like <<<<<<<< HEAD content from our side ======== content from their side >>>>>>>> MERGE_HEAD not <<<<<<<< MERGE_HEAD content from their side ======== content from our side >>>>>>>> HEAD The correct order usually comes naturally and for free, but with renames we often have data in the form {rename_branch, other_branch}, and working relative to the rename first (e.g. for rename/add) is more convenient elsewhere in the code. Address the slight impedance mismatch by having some functions re-call themselves with flipped arguments when the branch order is reversed. Note that setup_rename_conflict_info() has one asymmetry in it, in setting dst_entry1->processed=0 but not doing similarly for dst_entry2->processed. When dealing with rename/rename and similar conflicts, we do not want the processing to happen twice, so the desire to only set one of the entries to unprocessed is intentional. So, while this change modifies which branch's entry will be marked as unprocessed, that dovetails nicely with putting HEAD first so that we get the index stage entries and conflict markers in the right order. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-02Merge branch 'en/t6036-merge-recursive-tests'Libravatar Junio C Hamano1-0/+451
Tests to cover various conflicting cases have been added for merge-recursive. * en/t6036-merge-recursive-tests: t6036: add a failed conflict detection case: regular files, different modes t6036: add a failed conflict detection case with conflicting types t6036: add a failed conflict detection case with submodule add/add t6036: add a failed conflict detection case with submodule modify/modify t6036: add a failed conflict detection case with symlink add/add t6036: add a failed conflict detection case with symlink modify/modify
2018-08-02Merge branch 'es/test-fixes'Libravatar Junio C Hamano1-7/+7
Test clean-up and corrections. * es/test-fixes: (26 commits) t5608: fix broken &&-chain t9119: fix broken &&-chains t9000-t9999: fix broken &&-chains t7000-t7999: fix broken &&-chains t6000-t6999: fix broken &&-chains t5000-t5999: fix broken &&-chains t4000-t4999: fix broken &&-chains t3030: fix broken &&-chains t3000-t3999: fix broken &&-chains t2000-t2999: fix broken &&-chains t1000-t1999: fix broken &&-chains t0000-t0999: fix broken &&-chains t9814: simplify convoluted check that command correctly errors out t9001: fix broken "invoke hook" test t7810: use test_expect_code() instead of hand-rolled comparison t7400: fix broken "submodule add/reconfigure --force" test t7201: drop pointless "exit 0" at end of subshell t6036: fix broken "merge fails but has appropriate contents" tests t5505: modernize and simplify hard-to-digest test t5406: use write_script() instead of birthing shell script manually ...
2018-07-16t6000-t6999: fix broken &&-chainsLibravatar Eric Sunshine1-3/+3
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-12t6036: fix broken && chain in sub-shellLibravatar Ramsay Jones1-1/+1
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-11t6036: add a failed conflict detection case: regular files, different modesLibravatar Elijah Newren1-0/+67
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-06t6036: add lots of detail for directory/file conflicts in recursive caseLibravatar Elijah Newren1-55/+201
There was a discussion of problematic directory/file conflicts with virtual merge bases on the mailing list years ago at https://public-inbox.org/git/AANLkTimwUQafGDrjxWrfU9uY1uKoFLJhxYs=vssOPqdf@mail.gmail.com/ Part of these corresponding tests made it into this testsuite. However, the more problematic one didn't. And there are others that showcase the problems even more. Add a very lengthy explanation, some of it from that email, describing the tradeoffs in picking a recursive merge-base when you're dealing with an add/add directory/file conflict. The solution picked years ago is relatively good, but there is the potential to do even better, assuming we're willing to pay a certain performance cost. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t6036: add a failed conflict detection case with conflicting typesLibravatar Elijah Newren1-0/+75
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t6036: add a failed conflict detection case with submodule add/addLibravatar Elijah Newren1-0/+88
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t6036: add a failed conflict detection case with submodule modify/modifyLibravatar Elijah Newren1-0/+88
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t6036: add a failed conflict detection case with symlink add/addLibravatar Elijah Newren1-0/+66
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t6036: add a failed conflict detection case with symlink modify/modifyLibravatar Elijah Newren1-0/+67
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t6036: fix broken "merge fails but has appropriate contents" testsLibravatar Eric Sunshine1-4/+4
These tests reference non-existent object "c" when they really mean to be referencing "C", however, these errors went unnoticed due to a broken &&-chain later in the tests. Fix these errors, as well as the broken &&-chains behind which they hid. Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-28t6036: prefer test_when_finished to manual cleanup in following testLibravatar Elijah Newren1-10/+12
Manually cleaning up from former tests in subsequent ones breaks the ability to select which tests we want to run. Use test_when_finished to avoid this problem. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-28t6036, t6042: prefer test_cmp to sequences of testLibravatar Elijah Newren1-38/+71
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-28t6036, t6042: prefer test_path_is_file, test_path_is_missingLibravatar Elijah Newren1-2/+2
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-28t6036, t6042: use test_line_count instead of wc -lLibravatar Elijah Newren1-34/+68
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-28t6036, t6042: use test_create_repo to keep tests independentLibravatar Elijah Newren1-402/+452
These tests used pretty strong measures to get a clean slate: git rm -rf . && git clean -fdqx && rm -rf .git && git init && It's easier, safer (what if a previous test has a bug and accidentally changes into a directory outside the test path?), and allows re-inspecting test setup later if we instead just use test_create_repo to put different tests into separate sub-repositories. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>