> OK. We notice that we need to newly create foo/bar but we
> incorrectly find that there is "foo/bar" already because of the
> careless use of bare lstat(2) makes "bar" visible as if it were also
> "foo/bar". I wonder if the current code would be confused the same
> way if the side branch added "foo/bar/file", or the confusion would
> be even worse---it is not dir_in_way() and a different codepath
> would be affected, no?
I don't think there is a different codepath to be affected - as far as I
can tell, dir_in_way() is the only cause (at least of this particular
error). I've tested this case [1] and the current code actually works -
as you said, dir_in_way() will not report anything in the way (since
foo/bar/file doesn't exist in the working tree), so the merge will
happen as expected.
> Nicely done. Thanks, will queue.
Thanks.
[1]
diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index faa8892741..f284aeb173 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh
@@ -468,15 +468,16 @@ test_expect_success SYMLINKS 'dir in working tree with symlink ancestor does not
git checkout master &&
git rm foo &&
mkdir foo &&
- >foo/bar &&
- git add foo/bar &&
- git commit -m "replace foo symlink with real foo dir and foo/bar file" &&
+ mkdir foo/bar &&
+ >foo/bar/baz &&
+ git add foo/bar/baz &&
+ git commit -m "replace foo symlink with real foo dir and foo/bar/baz file" &&
git checkout branch1 &&
git cherry-pick master &&
test_path_is_dir foo &&
- test_path_is_file foo/bar
+ test_path_is_file foo/bar/baz
)
'
