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.
> 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.
> 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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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