Re: Request feature: –no-submodule

[Junio C Hamano <gitster@pobox.com>]

>> The original request, as I understand the clarification posted
>> ...
>> (cf. <9cc98ca3-bdc5-61bf-450a-99bb47673d6c@gmail.com>)
>> 
>> and with such an auto-pseudo-attribute, presumably something along
>> this line would work, removing the need for the intermediate filter:
>> 
>>     git ls-files \
>> 	':(attr:mode=100755)' ':(attr:mode=100644)' \
>> 	':(exclude)*.png' ':(exclude)*.ico' |
>>     xargs dos2unix
>> 
>
> Yeah, that makes sense.
>
> By the way, another reason (beyond a simpler pipeline) that the "magic
> pathspec that understands modes" is nicer is that it can be applied to a
> more dynamic set of paths.

In the longer term, the project the original request wanted to
invent the "--no-submodule" option for may want to lose the specific
"we know that the only paths we do not want to run dos2unix happen
to be png and ico files in the current codebase" from the above
sample command line, and replace it with something like ':(attr:text)'

Alas, the "text" attribute does *not* work that way, though ;-)
Just like any other attributes, what you assigned yourself counts,
and our "is this file a text?" auto-detection logic only kicks in
when there is no attribute that tells if a path is text or not.

It would be expensive at runtime; even if we were to introduce a
"dynamic" pseudo attribute to tell text files and others apart, we
probably shouldn't use the same "attr:*" magic but use something
distinct (e.g. "dynamic-attr:*") in order to make sure that the
users understand the performance implications.  I think the above
"mode=100755" matic (or anything that requires more than the basic
"which entries in the .gitattributes files does this pathname
match?") would fall into the same category.