summaryrefslogtreecommitdiff
path: root/t/t6022-merge-rename.sh
AgeCommit message (Collapse)AuthorFilesLines
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>