Re: Troubles when directory is replaced by symlink

> [Kjetil: I bisected this bug to your 92604b4. Details below.]
>
> On Tue, Jun 09, 2009 at 12:18:16PM +0400, Alexander Gladysh wrote:
>
>> Any help here? This bug is pretty annoying (especially that it
>> requires double hard resets).
>> 
>> Should I provide any extra information?
>
> Actually, I think the problem happens earlier than you realize; I see
> problems when switching back to master:
>
> -- >8 --
> # make a repo
> mkdir repo && cd repo && git init
>
> # content in alpha
> mkdir alpha && echo content >alpha/file && git add . && git commit -m one
> # and duplicate content inside beta
> mkdir beta && cp -R alpha beta && git add . && git commit -m two
>
> # now replace the duplicate with a symlink
> git checkout -b branch
> rm -rf beta/alpha && git add -u && git commit -m deleted
> ln -s ../alpha beta/alpha && git add . && git commit -m symlink
>
> # now checkout master again; alpha/file will be missing, even
> # though it wasn't touched at all
> git checkout master
> git status
> -- 8< --
>
> We handled this correctly in v1.6.1, so I was able to bisect it down to:
>
>     commit 92604b466344b2157efc42ef3521dac22d7906a2
>     Author: Kjetil Barvik <barvik@broadpark.no>
>     Date:   Sun Jan 18 16:14:50 2009 +0100
>
>         lstat_cache(): more cache effective symlink/directory detection
>
>         Make the cache functionality more effective.  Previously when
>         A/B/C/D was in the cache and A/B/C/E/file.c was called for,
>         there was no match at all from the cache.  Now we use the fact
>         that the paths "A", "A/B" and "A/B/C" are already tested, and we
>         only need to do an lstat() call on "A/B/C/E".
>
> I don't have time to look more closely now, but I'm guessing we are
> treating the symlink to the directory like the directory itself in a
> place that we shouldn't.
>
> -Peff