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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 11, 2012, 03:15 UTC
Message-ID: <7v8vbdaecl.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8CoedQBm4xyfhZX1mNTXpLMHxugygZUqOoZS8V5WVztGg@mail.gmail.com>

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

Show 17 quoted lines

> 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