Re: [PATCH] ls-files: fix overeager pathspec optimization

Linus Torvalds [off-list ref] writes:

On Fri, 8 Jan 2010, Junio C Hamano wrote:

quoted

Given pathspecs that share a common prefix, ls-files optimized its call
into recursive directory reader by starting at the common prefix
directory.

If you have a directory "t" with an untracked file "t/junk" in it, but the
top-level .gitignore file told us to ignore "t/", this resulted in an
unexpected behaviour:

Ok, I'm not sure how "unexpected" this is, since arguably you are 
overriding the ignore file by _being_ in that directory (the same way 
index contents override ignore files), but I could go either way on that.

Your patch looks fine, although I think you did this in a very odd way.

Actually, there is some funny interaction with "git add" I ran out of time
to figure out what the right fix should be:

    $ git init new
    $ cd new
    $ mkdir t
    $ >kuzu
    $ >t/gomi
    $ echo t >.gitignore
    $ echo kuzu >>.gitignore
    $ git add kuzu
    The following paths are ignored...
    kuzu
    Use -f if you really want to add them.
    $ git add t/gomi

Since "git add" uses the exact same codepath to find the untracked files
that match the pathspecs, I expected the "fix" will make it complain about
"t/gomi" being ignored.  Not so.

Actually, it does start ignoring t/gomi (the index does not have t/gomi
after the above sequence with the patch), but lack of the error message
makes it a rather unfortunate regression---it works as specified in the
sense that ignored paths are not added to the index unless --forced, but
it does so without telling the user about it.