> Jonathan Tan <jonathanta...@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.
