Re: Request feature: –no-submodule

quoted

The original request, as I understand the clarification posted
...
(cf. [off-list ref])

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.

If I understand correctly, we should learn to use git ls-files special 
parameters like 'attr' and 'exclude'. I'm impressed by the fact that 
these are not wide-spread known. We should learn to use these advanced 
features instead of extra piping. Your emails are precious to my team 
and will help us advance.

Please consider this request closed.
Ilias