summaryrefslogtreecommitdiff
path: root/t/t6022-merge-rename.sh
AgeCommit message (Collapse)AuthorFilesLines
2012-03-23merge-recursive: don't detect renames of empty filesLibravatar Jeff King1-0/+16
Merge-recursive detects renames so that if one side modifies "foo" and the other side moves it to "bar", the modification is applied to "bar". However, our rename detection is based on content analysis, it can be wrong (i.e., two files were not intended as a rename, but just happen to have the same or similar content). This is quite rare if the files actually contain content, since two unrelated files are unlikely to have exactly the same content. However, empty files present a problem, in that there is nothing to analyze. An uninteresting placeholder file with zero bytes may or may not be related to a placeholder file with another name. The result is that adding content to an empty file may cause confusion if the other side of a merge removed it; your content may end up in another random placeholder file that was added. Let's err on the side of caution and not consider empty files as renames. This will cause a modify/delete conflict on the merge, which will let the user sort it out themselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Avoid unnecessary file rewritesLibravatar Elijah Newren1-3/+3
Often times, a potential conflict at a path is resolved by merge-recursive by using the content that was already present at that location. In such cases, we do not want to overwrite the content that is already present, as that could trigger unnecessary recompilations. One of the patches earlier in this series ("merge-recursive: When we detect we can skip an update, actually skip it") fixed the cases that involved content merges, but there were a few other cases as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6022: Additional tests checking for unnecessary updates of filesLibravatar Elijah Newren1-0/+91
I stumbled across a case, this one not involving a content merge, where git currently rewrites a file unnecessarily. A quick audit uncovered two additional situations (also not involving content merges) with the same problem. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix spurious 'refusing to lose untracked file...' messagesLibravatar Elijah Newren1-1/+1
Calling update_stages() before update_file() can sometimes result in git thinking the file being updated is untracked (whenever update_stages moves it to stage 3). Reverse the call order, and add a big comment to update_stages to hopefully prevent others from making the same mistake. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6022: Add testcase for spurious "refusing to lose untracked" messagesLibravatar Elijah Newren1-0/+26
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Make modify/delete handling code reusableLibravatar Elijah Newren1-2/+2
modify/delete and rename/delete share a lot of similarities; we'd like all the criss-cross and D/F conflict handling specializations to be shared between the two. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: When we detect we can skip an update, actually skip itLibravatar Elijah Newren1-2/+2
In 882fd11 (merge-recursive: Delay content merging for renames 2010-09-20), there was code that checked for whether we could skip updating a file in the working directory, based on whether the merged version matched the current working copy. Due to the desire to handle directory/file conflicts that were resolvable, that commit deferred content merging by first updating the index with the unmerged entries and then moving the actual merging (along with the skip-the-content-update check) to another function that ran later in the merge process. As part moving the content merging code, a bug was introduced such that although the message about skipping the update would be printed (whenever GIT_MERGE_VERBOSITY was sufficiently high), the file would be unconditionally updated in the working copy anyway. When we detect that the file does not need to be updated in the working copy, update the index appropriately and then return early before updating the working copy. Note that there was a similar change in b2c8c0a (merge-recursive: When we detect we can skip an update, actually skip it 2011-02-28), but it was reverted by 6db4105 (Revert "Merge branch 'en/merge-recursive'" 2011-05-19) since it did not fix both of the relevant types of unnecessary update breakages and, worse, it made use of some band-aids that caused other problems. The reason this change works is due to the changes earlier in this series to (a) record_df_conflict_files instead of just unlinking them early, (b) allowing make_room_for_path() to remove D/F entries, (c) the splitting of update_stages_and_entry() to have its functionality called at different points, and (d) making the pathnames of the files involved in the merge available to merge_content(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Provide more info in conflict markers with file renamesLibravatar Elijah Newren1-4/+71
Whenever there are merge conflicts in file contents, we would mark the different sides of the conflict with the two branches being merged. However, when there is a rename involved as well, the branchname is not sufficient to specify where the conflicting content came from. In such cases, mark the two sides of the conflict with branchname:filename rather than just branchname. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Improve handling of rename target vs. directory additionLibravatar Elijah Newren1-2/+2
When dealing with file merging and renames and D/F conflicts and possible criss-cross merges (how's that for a corner case?), we did not do a thorough job ensuring the index and working directory had the correct contents. Fix the logic in merge_content() to handle this. Also, correct some erroneous tests in t6022 that were expecting the wrong number of unmerged index entries. These changes fix one of the tests in t6042 (and almost fix another one from t6042 as well). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6022: Add testcase for merging a renamed file with a simple changeLibravatar Elijah Newren1-0/+27
This is a testcase that was broken by b2c8c0a (merge-recursive: When we detect we can skip an update, actually skip it 2011-02-28) and fixed by 6db4105 (Revert "Merge branch 'en/merge-recursive'" 2011-05-19). Include this testcase to ensure we don't regress it again. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6022: New tests checking for unnecessary updates of filesLibravatar Elijah Newren1-0/+63
This testcase was part of en/merge-recursive that was reverted in 6db4105 (Revert "Merge branch 'en/merge-recursive'" 2011-05-19). While the other changes in that series caused unfortunate breakage, this testcase is still useful; reinstate it. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14t6022: Remove unnecessary untracked files to make test cleanerLibravatar Elijah Newren1-0/+1
Since this test later does a git add -A, we should clean out unnecessary untracked files as part of our cleanup. 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-0/+366
* 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-17t6022: Use -eq not = to test output of wc -lLibravatar Brian Gernhardt1-32/+32
When comparing numbers such as "3" to "$(wc -l)", we should check for numerical equality using -eq instead of string equality using = because some implementations of wc output extra whitespace. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09t6022 (renaming merge): chain test commands with &&Libravatar Jonathan Nieder1-190/+92
Using 'return' in an attempt to end a test assertion can have unpredictable results (probably escaping from test_run_ and breaking its bookkeeping). Redo the control flow using helpers like test_expect_code and git diff --exit-code, so each test assertion can follow the usual form command that should succeed && command that should succeed && command that should succeed && ... Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29merge_content(): Check whether D/F conflicts are still presentLibravatar Elijah Newren1-4/+4
If all the paths below some directory involved in a D/F conflict were not removed during the rest of the merge, then the contents of the file whose path conflicted needs to be recorded in file with an alternative filename. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29conflict_rename_rename_1to2(): Fix checks for presence of D/F conflictsLibravatar Elijah Newren1-1/+1
This function is called from process_df_entry(), near the end of the merge. Rather than just checking whether one of the sides of the merge had a directory at the same path as one of our files, check whether that directory is still present by this point of our merge. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29conflict_rename_delete(): Check whether D/F conflicts are still presentLibravatar Elijah Newren1-2/+2
If all the paths below some directory involved in a D/F conflict were not removed during the rest of the merge, then the contents of the file whose path conflicted needs to be recorded in file with an alternative filename. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29merge-recursive: Delay content merging for renamesLibravatar Elijah Newren1-1/+1
Move the handling of content merging for renames from process_renames() to process_df_entry(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29merge-recursive: Move handling of double rename of one file to twoLibravatar Elijah Newren1-1/+1
Move the handling of rename/rename conflicts where one file is renamed to two different files, from process_renames() to process_df_entry(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29t6022: Add tests for rename/rename combined with D/F conflictsLibravatar Elijah Newren1-0/+79
Add tests where one file is renamed to two different paths in different sides of history, and where each of the new files matches the name of a directory from the opposite side of history. Include tests for both the case where the merge results in those directories not being cleanly removed, and where those directories are cleanly removed during the merge. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29t6022: Add paired rename+D/F conflict: (two/file, one/file) -> (one, two)Libravatar Elijah Newren1-0/+63
An interesting testcase is having two files each in their own subdirectory getting renamed to the toplevel at the directory pathname of the other. Questions arise as to whether the order of operations matters and whether the directories can correctly get out of the way and make room for the new files. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29t6022: Add tests with both rename source & dest involved in D/F conflictsLibravatar Elijah Newren1-0/+38
Having the source of a rename be involved in a directory/file conflict does not currently pose any difficulties to the current merge-recursive algorithm (in contrast to destinations of renames and D/F conflicts). However, combining the two seemed like good testcases to include for completeness. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29t6022: Add tests for reversing order of merges when D/F conflicts presentLibravatar Elijah Newren1-0/+58
When merging two branches with some path involved in a D/F conflict, the choice of which branch to merge into the other matters for (at least) two reasons: (1) whether the working copy has a directory full of files that is in the way of a file, or a file exists that is in the way of a directory of files, (2) when the directory full of files does not disappear due to the merge, what files at the same paths should be renamed to (e.g. filename~HEAD vs. filename~otherbranch). Add some tests that reverse the merge order of two other tests, and which verify the contents are as expected (namely, that the results are identical other than modified-for-uniqueness filenames involving branch names). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29t6022: Add test combinations of {content conflict?, D/F conflict remains?}Libravatar Elijah Newren1-0/+128
Add testing of the various ways that a renamed file to a path involved in a directory/file conflict may be involved in. This includes whether or not there are conflicts of the contents of the renamed file (if the file was modified on both sides of history), and whether the directory from the other side of the merge will disappear as a result of the merge or not. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31tests: use "test_cmp", not "diff", when verifying the resultLibravatar Gary V. Vaughan1-2/+2
In tests, call test_cmp rather than raw diff where possible (i.e. if the output does not go to a pipe), to allow the use of, say, 'cmp' when the default 'diff -u' is not compatible with a vendor diff. When that is not possible, use $DIFF, as set in GIT-BUILD-OPTIONS. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-25Add a test for merging changed and rename-changed branchesLibravatar Alex Riesen1-0/+23
Also leave a warning for future merge-recursive explorers. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-27t6022: ignoring untracked files by merge-recursive when they do not matterLibravatar Junio C Hamano1-23/+142
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-27tests: merge-recursive is usable without PythonLibravatar Junio C Hamano1-6/+0
Many tests still protected themselves with $no_python; there is no need to do so anymore. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17read-tree -m -u: do not overwrite or remove untracked working tree files.Libravatar Junio C Hamano1-0/+1
When a merge results in a creation of a path that did not exist in HEAD, and if you already have that path on the working tree, because the index has not been told about the working tree file, read-tree happily removes it. The issue was brought up by Santi BĂ©jar on the list. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-18Optionally work without pythonLibravatar Johannes Schindelin1-0/+6
In some setups (notably server setups) you do not need that dependency. Gracefully handle the absence of python when NO_PYTHON is defined. Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21merge-recursive: conflicting rename case.Libravatar Junio C Hamano1-0/+37
This changes the way the case two branches rename the same path to different paths is handled. Earlier, the code removed the original path and added both destinations to the index at stage0. This commit changes it to leave the original path at stage1, and two destination paths at stage2 and stage3, respectively. [jc: I am not really sure if this makes much difference in the real life merge situations. What should happen when our branch renames A to B and M to N, while their branch renames A to M? That is, M remains in our tree as is.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-11t/t6022: a new test for renaming merge.Libravatar Junio C Hamano1-0/+164
This adds a couple of tests to cover the following renaming merge cases: - one side renames and the other side does not, with and without content conflicts. - both side rename to the same path, with and without content conflicts. The test setup also prepares a case in which both side rename to different destination, but currently the code collapses these destination paths and removes the original path, which may be wrong. The outcome of this case is not checked by the tests in this round. Signed-off-by: Junio C Hamano <junkio@cox.net>