Re: Bug report about symlinks

> I think you, who dug to find out where to add the check, already
> know this, and I am writing this mainly for myself and for the list
> archive, but when the knee-jerk "has-syjmlink-leading-path missing?"
> reaction came to me, two obvious optimizations also came to my mind:
>
>  - When checking a cache entry "a/b/c/d/e" and we find out "a/b/c"
>    is a symbolic link, we mark it as ~CE_VALID, but at the same
>    time, we learn "a/b/c/any/thing" are also ~CE_VALID with that
>    check, so we _could_, after the has_symlink_leading_path once
>    returns true, so there may be an opportunity to fast-forward the
>    scan, marking all paths under "a/b/c" as ~CE_VALID.
>
>  - After finding out "a/b/c" is a symbolic link to cause anything
>    underneath marked as ~CE_VALID, we also know "a/" and "a/b/"
>    exists as real directories, so a later check for "a/b/some/thing"
>    can start checking at "a/b/some/" without checking "a/" and "a/b/".

> The latter is more important as it is a much more common case that
> the shape of the working tree not to change.
>
> But I think the implementation of has_symlink_leading_path() already
> has these optimizations built inside around the (unfortunately named)
> "struct cache_def", so it probably would not give us much boost to
> implement such a fast-forwarding of the scan.