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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 9, 2010, 00:06 UTC
Message-ID: <7v3a2gnnv2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.2.00.1001081520240.7821@localhost.localdomain>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 15 quoted lines

> On Fri, 8 Jan 2010, Junio C Hamano wrote:
>>
>> 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.