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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 17, 2019, 22:23 UTC
Message-ID: <xmqqh85a7eax.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190917215040.132503-1-jonathantanmy@google.com>

Jonathan Tan <jonathantanmy@google.com> writes:

> When the working tree has:
>  - foo (symlink)
>  - foo/bar (directory)

Whoa, wait. I assume, since this is about merge, the assumption is that the working tree is clean with respect to the index, so 'foo' is a symbolic link that is in the index. Now, if foo is a symlink, how can foo/bar (whether it is a directory or something else) exist, which requires foo to be a directory in the first place?

> and the user merges a commit that deletes the foo symlink and instead
> contains:
>  - foo (directory)
>  - foo/bar (file)

This side is possible. If foo is a directory, then there can be foo/bar. But I do not get the initial setup you start with.

In any case, if the working tree has 'foo' as a symlink, Git should not look at or get affected by what 'foo' points at.