>> The original request, as I understand the clarification posted >> ... >> (cf. <9cc98ca3-bdc5-61bf-450a-99bb47673d6c@xxxxxxxxx>) >> >> 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.
