Duy Nguyen 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
Charles Bailey writes:
> http://thread.gmane.org/gmane.comp.version-control.git/272363/focus=276358
>
> http://thread.gmane.org/gmane.comp.version-control.git/283001/focus=283002
>
> Unless I've misunderstood the conversation and commit message, the
> referenced commit was
On Thu, Jun 16, 2016 at 6:44 PM, Charles Bailey wrote:
> On Thu, Jun 16, 2016 at 05:57:18PM +0700, Duy Nguyen wrote:
>>
>> "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
On Thu, Jun 16, 2016 at 05:57:18PM +0700, Duy Nguyen wrote:
>
> "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
On Thu, Jun 16, 2016 at 4:47 PM, Charles Bailey wrote:
> On Thu, Jun 16, 2016 at 02:47:09PM +0700, Duy Nguyen wrote:
>> I don't think revert is right. It rather needs a re-fix like below.
>> Basically we want grep_file() to run as normal, but grep_sha1()
>> (i.e. git grep
On Thu, Jun 16, 2016 at 02:47:09PM +0700, Duy Nguyen wrote:
> I don't think revert is right. It rather needs a re-fix like below.
> Basically we want grep_file() to run as normal, but grep_sha1()
> (i.e. git grep --cached) should ignore i-t-a entries, because empty
> SHA-1 is not the right content
On Thu, Jun 16, 2016 at 07:53:24AM +0100, Charles Bailey wrote:
> From: Charles Bailey
>
> This reverts commit 4d552005323034c1d6311796ac1074e9a4b4b57e.
>
> This commit caused 'git grep' to no longer find matches in new files in
> the working tree where the
From: Charles Bailey
This reverts commit 4d552005323034c1d6311796ac1074e9a4b4b57e.
This commit caused 'git grep' to no longer find matches in new files in
the working tree where the corresponding index entry had the "intent to
add" bit set.
Add tests to cover this case
8 matches
Mail list logo