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.

---
This commit is based on top of sb/test-cherry-pick-submodule-getting-in-a-way.

 merge-recursive.c                | 5 +++--
 t/t3512-cherry-pick-submodule.sh | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

index 1d3f8f0d22..9fb0b9f8fd 100644
@@ -1901,8 +1901,9 @@ static int process_entry(struct merge_options *o,
 			oid = b_oid;
 			conf = _("directory/file");
 		}
-		if (dir_in_way(path, !o->call_depth,
-			       S_ISGITLINK(a_mode))) {
+		if (dir_in_way(path,
+			       !o->call_depth && !S_ISGITLINK(a_mode),
+			       0)) {
 			char *new_path = unique_path(o, path, add_branch);
 			clean_merge = 0;
 			output(o, 1, _("CONFLICT (%s): There is a directory with name %s in %s. "

index 1b1e31100f..ce48c4fcca 100755
@@ -10,7 +10,7 @@ KNOWN_FAILURE_NOFF_MERGE_DOESNT_CREATE_EMPTY_SUBMODULE_DIR=1
 KNOWN_FAILURE_NOFF_MERGE_ATTEMPTS_TO_MERGE_REMOVED_SUBMODULE_FILES=1
 test_submodule_switch "git cherry-pick"
 
-test_expect_failure 'unrelated submodule/file conflict is ignored' '
+test_expect_success 'unrelated submodule/file conflict is ignored' '
 	test_create_repo sub &&
 
 	touch sub/file &&

2.15.0.2.g63e86ab1a0

+cc Ефимов Василий <[email protected]> who reported the issue at
https://public-inbox.org/git/[email protected]/

Thanks for getting the discussion started here (and fixing the bug), based on your input in
https://public-inbox.org/git/CABPp-BHDrw_dAESic3xK7kC3jMgKeNQuPQF69OpbVYhRkbhJsw@mail.gmail.com/
I adapted the test case locally to have two tests one file/submodule and a submodule/file conflict, after the setup which boroows a lot of code from the
existing test, we'll have:

    test_expect_success 'unrelated submodule/file conflict is ignored' '
    (
        cd a_repo &&
       git checkout with_sub^0 &&
        git cherry-pick with_file^0
    )
    '

    test_expect_success 'unrelated file/submodule conflict is ignored' '
    (
        cd a_repo &&
        git checkout with_file^0 &&
        git cherry-pick with_sub^0
    )
    '

and the other case now fails. I'll take a look into that. I think we'd need to check either a_mode or b_mode to be a submodule depending on which side the submodule occured.

So I'll build on top of this patch to fix the other way, too.

This makes no sense, yet. Sorry about the noise.
I think your patch is fine as is.