Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

[Junio C Hamano <gitster@pobox.com>]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> +     git commit -m new &&
>>> +     echo "Binary file HEAD:t matches" >expect &&
>>> +     git grep text HEAD -- t >actual &&
>>> +     test_cmp expect actual &&
>>> +     git reset HEAD^
>>> +'
>>
>> And in yet another test, should
>>
>>         git grep text HEAD:t
>>
>> /not/ respect the binary attribute?
>
> Gray area. Is it ok to do that without documenting it (i.e. common
> sense)? I have something in mind that could do that, but it also makes
> "git grep text HEAD^{tree}" not respect attributes.

Personally, I do not think HEAD:t is worth worrying about.

We could use the get_sha1_with_context() to get "t" out of "HEAD:t",
and we could even enhance get_sha1_with_context() to also preserve
the value of what came before the colon, but that would mean that
these three

    git grep text HEAD:t/t0200
    git grep text $(git rev-parse HEAD:t/t0200)
    git grep text $(git rev-parse HEAD:t):t0200

would behave differently; only the first one has any chance of
applying the correct set of ".gitattributes".  All of them would be
able to use the ".gitattributes" file contained in the tree object
that corresponds to t/t0200 (if we updated attr.c to read from tree
objects, that is), but the latter two would skip ".gitattributes"
files from the top-level and "t" directories, still using the final
fallback definition from $GIT_DIR/info/attributes file.

If we have to draw a line somewhere, the saner place to draw it is
to stop at

    git grep text HEAD -- t/t0200