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

From: Jonathan Tan <jonathantanmy@google.com>
To: gitster@pobox.com
Cc: jonathantanmy@google.com, git@vger.kernel.org, newren@gmail.com
Subject: Re: [RFC PATCH] merge-recursive: symlink's descendants not in way
Date: Tue, 17 Sep 2019 15:32:36 -0700	[thread overview]
Message-ID: <20190917223236.149613-1-jonathantanmy@google.com> (raw)
In-Reply-To: <xmqqh85a7eax.fsf@gitster-ct.c.googlers.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?

I was trying to be concise but I guess I omitted too much detail. This is
what's happening:

Working tree:
 - foo (symlink pointing to .)
 - bar (directory)
 - bar/file (file)

And the new commit:
 - foo (directory)
 - foo/bar (file)
 - bar (directory)
 - bar/file (file)

I'll update the commit message when I send out another version.

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

Git should not, but it does - there is a call in process_entry() that calls
lstat() on "foo/bar", which indeed reports that "foo/bar" is a directory. This
patch adds a check that none of its ancestors are symlinks.