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

Nguyen Thai Ngoc Duy [off-list ref] writes:

On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt [off-list ref] wrote:

quoted

quoted

+     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