Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> 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.
--
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