Re: [PATCH] grep: fix grepping for "intent to add" files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Duy Nguyen <pclouds@xxxxxxxxx> writes:

>> You don't think the revert is correct or you don't think the revert is
>> sufficient? (I wasn't able to find a test case which proved that the
>> change to line 399 was necessary, so perhaps I don't understand.)
>
> OK insufficient.
>
>> I would have thought that grepping the empty SHA-1 would be correct for
>> with or without -v. An "intent to add" file has no content in the index
>> so I would expect it to have zero matching and zero non-matching lines
>> for any grep --cached query?
>>
>> Or is this an efficiency and not a correctness concern?
>
> "git grep --cached" searches file content that will be committed by
> "git commit" (no -a). An i-t-a entry will not be committed (you would
> need "git add" first, or do "git commit -a"). So if I say "search
> among the to-be-committed file content, list files that do not match
> abc" (git grep -l -v --cached abc), the i-t-a entry will show up
> because its fake content is empty (i.e. not contain "abc"), even
> though it's not in the "to-be-committed" list. So yeah, correctness
> issue.

OK, sounds like a good start for a proper log message for the fix.
Thanks for hashing it all out before I got to the end of the thread
;-)
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]