Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes:
> On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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
--
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