Re: [PATCH] Unify the use of standard set of exclude files

By the way, I think the way in which excluded() is called inside ls-files for --cached, --staged, --deleted and --modified is totally bogus, and as a result, ls-files does not honor per-directory exclude files properly.

This is because dir.c:excluded() needs to be called after setting up the exclude_list stack properly, just like how dir.c:read_directory() and unpack-trees.c:unpack_trees_rec() do. The directory traversal should look like this:

 - Call push_exclude_per_directory() upon entering a directory.
   This reads the per directory exclude file (.gitignore) from
   the directory, and push it into the existing stack.  This
   way, the patterns from the file is set up to override the
   existing patterns from the .gitignore files of higher level
   directories.

 - Ask excluded() if your paths in that directory matches, and
   do whatever you want to happen.

 - Call pop_exclude_per_directory() when leaving the directory,
   to free the patterns read from the .gitignore file there.

Because the codepaths in question just iterate over the cache entries without telling the per-directory exclude file stack which set of .gitignore files should apply to the inquiry using push/pop mechanism, I _think_ excluded(dir, "a/b") calls in the codepaths do not honor .gitignore nor a/.gitignore file when checking if "a/b" is to be ignored.

The push/pop mechanism was designed to be used in read_directory() and it was a good match to the code structure to make recursive calls to read_directory_recursive(). Because the paths are sorted in the pathname order, we can make appropriate calls to push/pop while iterating over the cache in these codepaths to fix this issue.

As a longer term fix, I think it makes more sense to make excluded() automatically push/pop the per directory exclude file stack, just like the gitattributes mechanism maintains the attribute stack to match and cache the last checked path.