Re: [PATCH] Don't search files with an unset "grep" attribute

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Jan 26, 2012, 16:45 UTC
Message-ID: <4F21831C.7060609@alum.mit.edu>
In-Reply-To: <20120125214625.GA4666@sigill.intra.peff.net>

On 01/25/2012 10:46 PM, Jeff King wrote:

> But what I'm not sure I agree with is that the idea of "I don't want to
> include path X in my grep" maps to "just mark the file as binary".

Anybody who wants this policy can simply set

    [attr]binary -diff -text -grep

If they want finer granularity, they can adjust the settings for particular file types or for particular files.

Show 7 quoted lines

> But should I mark everything in compat/nedmalloc as binary? I don't
> think so. I _do_ want to see changes in nedmalloc in "git log" or "git
> diff". They don't bother me because they're infrequent, and we still
> want to produce regular text patches for the list when they come up. But
> because nedmalloc contains a lot of lines of code (even though they
> don't change a lot), it happens to produce a lot of uninteresting
> matches when grepping.

I think decisions such as whether to include an imported module in "git diff" output is a personal preference and should not be decided at the level of the git project. The in-tree .gitattributes files should, by and large, just *describe* the files and leave it to users to associate policies with the tags (or at least make it possible for users to override the policies) via .git/info/attributes. For example, the repository could set an "external=nedmalloc" attribute on all files under compat/nedmalloc, and users could themselves configure a macro "[attr]external -diff -grep" (or maybe something like "[attr]external=nedmalloc -diff -grep") if that is their preference.

Show 6 quoted lines

> It would be nice to be able to treat them differently in the cases you
> wanted to, but not _have_ to do so. Attribute macros can almost
> implement this. You could add "-grep" to binary. But you can't (as far
> as I know) do "macro=foo" to handle arbitrary diff drivers. I suspect we
> could extend the rules to allow macros that take an argument and pass it
> to their constituent attributes.

Is it really common to want to use the same argument on multiple macros without also wanting to set other things specifically? If not, then there is not much reason to complicate macros with argument support.

For example, I do something like

    [attr]type-python type=python text diff=python check-ws
    *.py type-python

    [attr]type-makefile type=makefile text diff check-ws -check-tab
    Makefile.* type-makefile

for the main file types in my repository, and it is not very cumbersome.

"type-python" and "type=python" seem redundant but they are not. "type-python" is needed so that it can be used as a macro. "type=python" makes it easier to inquire about the type of a file using something like "git check-attr type -- PATH" rather than having to inquire about each possible type-* attribute. It might be nice to support a slightly extended macro definition syntax like

    [attr]type=python text diff=python check-ws
    *.py type=python

    [attr]type=makefile text diff check-ws -check-tab
    Makefile.* type=makefile

(i.e., macros that are only triggered for particular values of an attribute).

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/