On Mon, Aug 4, 2014 at 12:19 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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/". Just checking, you meant CE_UPTODATE, not CE_VALID, right? CE_VALID is only used with --assume-unchanged > 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. Yeah my first thought is another flood of lstat(). But it looks like has_symlink_leading_path() tries hard to reduce lstat() already. We could disable this call in filesytems that do not support symlinks (e.g. vfat) but I guess that's just a minority. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html