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.