Re: [PATCH v2] merge-recursive: symlink's descendants not in way

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 20, 2019, 20:38 UTC
Message-ID: <xmqq8sqiu2in.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190920202506.74644-1-jonathantanmy@google.com>

Jonathan Tan <jonathantanmy@google.com> writes:

Show 11 quoted lines

>> 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?

In that case, thanks for a very good news and for a careful analysis.