> Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > > >> 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). > > OK, so existing code already realizes that "foo/bar/file" added in > the side branch is the one that must survive, and the "bar/file" in > the current branch does not fool it into thinking that "foo/bar/file" > is also on our end, and needs to be merged as an add-add conflict. > It was only the dir-in-the-way logic that was not careful enough? Yes, that's correct. (I wrote foo/bar/baz in my other email but replaced "baz" with "file", and it still works before and after my patch.) > In that case, thanks for a very good news and for a careful analysis. You're welcome! The careful analysis should be credited to Elijah Newren [1]. [1] https://public-inbox.org/git/CABPp-BHpXWF+1hKUTfn8s-y4MJZXz+jUVS_K10eKyD6PGwo=gg@xxxxxxxxxxxxxx/
