Re: [RFC PATCH] merge-recursive: symlink's descendants not in way
- From
- Jonathan Tan <jonathantanmy@google.com>
- Date
- Sep 17, 2019, 22:32 UTC
- Message-ID
- <20190917223236.149613-1-jonathantanmy@google.com>
- In-Reply-To
- <xmqqh85a7eax.fsf@gitster-ct.c.googlers.com>
Show 11 quoted lines
> 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.