summaryrefslogtreecommitdiff
path: root/t/t6020-merge-df.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-07-31read-cache: fix directory/file conflict handling in read_index_unmerged()Libravatar Elijah Newren1-3/+0
read_index_unmerged() has two intended purposes: * return 1 if there are any unmerged entries, 0 otherwise * drops any higher-stage entries down to stage #0 There are several callers of read_index_unmerged() that check the return value to see if it is non-zero, all of which then die() if that condition is met. For these callers, dropping higher-stage entries down to stage #0 is a waste of resources, and returning immediately on first unmerged entry would be better. But it's probably only a very minor difference and isn't the focus of this series. The remaining callers ignore the return value and call this function for the side effect of dropping higher-stage entries down to stage #0. As mentioned in commit e11d7b596970 ("'reset --merge': fix unmerged case", 2009-12-31), The _only_ reason we want to keep a previously unmerged entry in the index at stage #0 is so that we don't forget the fact that we have corresponding file in the work tree in order to be able to remove it when the tree we are resetting to does not have the path. In fact, prior to commit d1a43f2aa4bf ("reset --hard/read-tree --reset -u: remove unmerged new paths", 2008-10-15), read_index_unmerged() did just remove unmerged entries from the cache immediately but that had the unwanted effect of leaving around new untracked files in the tree from aborted merges. So, that's the intended purpose of this function. The problem is that when directory/files conflicts are present, trying to add the file to the index at stage 0 fails (because there is still a directory in the way), and the function returns early with a -1 return code to signify the error. As noted above, none of the callers who want the drop-to-stage-0 behavior check the return status, though, so this means all remaining unmerged entries remain in the index and the callers proceed assuming otherwise. Users then see errors of the form: error: 'DIR-OR-FILE' appears as both a file and as a directory error: DIR-OR-FILE: cannot drop to stage #0 and potentially also messages about other unmerged entries which came lexicographically later than whatever pathname was both a file and a directory. Google finds a few hits searching for those messages, suggesting there were probably a couple people who hit this besides me. Luckily, calling `git reset --hard` multiple times would workaround this bug. Since the whole purpose here is to just put the entry *temporarily* into the index so that any associated file in the working copy can be removed, we can just skip the DFCHECK and allow both the file and directory to appear in the index. The temporary simultaneous appearance of the directory and file entries in the index will be removed by the callers by calling unpack_trees(), which excludes these unmerged entries marked with CE_CONFLICTED flag from the resulting index, before they attempt to write the index anywhere. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-29merge: deprecate 'git merge <message> HEAD <commit>' syntaxLibravatar Junio C Hamano1-1/+1
We had this in "git merge" manual for eternity: 'git merge' <msg> HEAD <commit>... [This] syntax (<msg> `HEAD` <commit>...) is supported for historical reasons. Do not use it from the command line or in new scripts. It is the same as `git merge -m <msg> <commit>...`. With the update to "git merge" to make it understand what is recorded in FETCH_HEAD directly, including Octopus merge cases, we now can rewrite the use of this syntax in "git pull" with a simple "git merge FETCH_HEAD". Also there are quite a few fallouts in the test scripts, and it turns out that "git cvsimport" also uses this old syntax to record a merge. Judging from this result, I would not be surprised if dropping the support of the old syntax broke scripts people have written and been relying on for the past ten years. But at least we can start the deprecation process by throwing a warning message when the syntax is used. With luck, we might be able to drop the support in a few years. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-14merge-recursive: Fix sorting order and directory change assumptionsLibravatar Elijah Newren1-8/+18
We cannot assume that directory/file conflicts will appear in sorted order; for example, 'letters.txt' comes between 'letters' and 'letters/file'. Thanks to Johannes for a pointer about qsort stability issues with Windows and suggested code change. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-29Merge branch 'en/merge-recursive'Libravatar Junio C Hamano1-13/+63
* 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-10-06test-lib: make test_expect_code a test commandLibravatar Ævar Arnfjörð Bjarmason1-1/+3
Change test_expect_code to be a normal test command instead of a top-level command. As a top-level command it would fail in cases like: test_expect_code 1 'phoney' ' foo && bar && (exit 1) ' Here the test might incorrectly succeed if "foo" or "bar" happened to fail with exit status 1. Instead we now do: test_expect_success 'phoney' ' foo && bar && test_expect_code 1 "(exit 1)" ' Which will only succeed if "foo" and "bar" return status 0, and "(exit 1)" returns status 1. Note that test_expect_code has been made slightly noisier, as it reports the exit code it receives even upon success. Some test code in t0000-basic.sh relied on the old semantics of test_expect_code to test the test_when_finished command. I've converted that code to use an external test similar to the TODO test I added in v1.7.3-rc0~2^2~3. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29merge-recursive: Make room for directories in D/F conflictsLibravatar Elijah Newren1-1/+1
When there are unmerged entries present, make sure to check for D/F conflicts first and remove any files present in HEAD that would be in the way of creating files below the correspondingly named directory. Such files will be processed again at the end of the merge in process_df_entry(); at that time we will be able to tell if we need to and can reinstate the file, whether we need to place its contents in a different file due to the directory still being present, etc. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29handle_delete_modify(): Check whether D/F conflicts are still presentLibravatar Elijah Newren1-1/+1
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-29t6020: Add a testcase for modify/delete + directory/file conflictLibravatar Elijah Newren1-0/+47
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29t6020: Modernize style a bitLibravatar Elijah Newren1-15/+20
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-09merge_recursive: Fix renames across paths below D/F conflictsLibravatar Elijah Newren1-1/+1
The rename logic in process_renames() handles renames and merging of file contents and then marks files as processed. However, there may be higher stage entries left in the index for other reasons (e.g., due to D/F conflicts). By checking for such cases and marking the entry as not processed, it allows process_entry() later to look at it and handle those higher stages. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29Add a reminder test case for a merge with F/D transitionLibravatar Alex Riesen1-0/+23
The problem is that if a file was replaced with a directory containing another file with the same content and mode, an attempt to merge it with a branch descended from a commit before this F->D transition will cause merge-recursive to break. It breaks even if there were no conflicting changes on that other branch. Originally reported by Anders Melchiorsen. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2005-12-03New test case: merge with directory/file conflictsLibravatar Fredrik Kuivinen1-0/+25
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>