merge-recursive: handle addition of submodule on our side of history

The code for a newly added path assumed that the path was a normal file, and thus checked for there being a directory still being in the way of the file. Note that since unpack_trees() does path-in-the-way checks already, the only way for there to be a directory in the way at this point in the code, is if there is some kind of D/F conflict in the merge. For a submodule addition on HEAD's side of history, the submodule would have already been present. This means that we do expect there to be a directory present but should not consider it to be "in the way"; instead, it's the expected submodule. So, when there's a submodule addition from HEAD's side, don't bother checking the working copy for a directory in the way. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Elijah Newren committed Nov 14, 2017 at 09:31 UTC c641ca67072946f95f87e7b21f13f3d4e73701e3
2 files changed +4 -3
merge-recursive.c
+3 -2
@@ -1901,8 +1901,9 @@ static int process_entry(struct merge_options *o,
1901 oid = b_oid;
1902 conf = _("directory/file");
1903 }
1904 - if (dir_in_way(path, !o->call_depth,
1905 - S_ISGITLINK(a_mode))) {
1904 + if (dir_in_way(path,
1905 + !o->call_depth && !S_ISGITLINK(a_mode),
1906 + 0)) {
1907 char *new_path = unique_path(o, path, add_branch);
1908 clean_merge = 0;
1909 output(o, 1, _("CONFLICT (%s): There is a directory with name %s in %s. "
t/t3512-cherry-pick-submodule.sh
+1 -1
@@ -10,7 +10,7 @@ KNOWN_FAILURE_NOFF_MERGE_DOESNT_CREATE_EMPTY_SUBMODULE_DIR=1
10 KNOWN_FAILURE_NOFF_MERGE_ATTEMPTS_TO_MERGE_REMOVED_SUBMODULE_FILES=1
11 test_submodule_switch "git cherry-pick"
12
13 -test_expect_failure 'unrelated submodule/file conflict is ignored' '
13 +test_expect_success 'unrelated submodule/file conflict is ignored' '
14 test_create_repo sub &&
15
16 touch sub/file &&