Jeff King [off-list ref] writes:
It doesn't seem outrageous to me for Git to automatically populate
"pseudo-attributes" that connect properties of paths to the attribute
system.
Sounds sensible. The attribute assignment was designed to purely
depend on paths and not contents, so it might be a bit awkwarad to
implement, but it should be doable.
An alternative view is allowing a pathspec that asks about the mode:
git ls-files ':(mode=160000)'
That also lets you ask about other things, like:
git ls-files ':(mode=100755)'
but it is probably unnecessarily arcane (even I had to look up the
correct mode for a gitlink just now :) ).
The original request, as I understand the clarification posted
upthread, is not "submodules are uninteresting", but is "we want
regular files" (and we postprocess further the output), so such a
"mode" (pseudo-)attribute that is automatically populated would be a
better fit anyway. With the current system, they can already do:
git ls-files -s ':(exclude)*.png' ':(exclude)*.ico)' |
sed -n -e 's/^100[76][54][54] [0-9a-f]* 0 //p' |
xargs dos2unix
(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
On Fri, Jun 04, 2021 at 06:54:10AM +0900, Junio C Hamano wrote:
quoted
An alternative view is allowing a pathspec that asks about the mode:
git ls-files ':(mode=160000)'
That also lets you ask about other things, like:
git ls-files ':(mode=100755)'
but it is probably unnecessarily arcane (even I had to look up the
correct mode for a gitlink just now :) ).
The original request, as I understand the clarification posted
upthread, is not "submodules are uninteresting", but is "we want
regular files" (and we postprocess further the output), so such a
"mode" (pseudo-)attribute that is automatically populated would be a
better fit anyway. With the current system, they can already do:
git ls-files -s ':(exclude)*.png' ':(exclude)*.ico)' |
sed -n -e 's/^100[76][54][54] [0-9a-f]* 0 //p' |
xargs dos2unix
(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.
For instance, you could use a pipeline like the one you showed above to
limit the ls-files output, and then you could feed that set of literal
paths to a command like "git add" (perhaps with --literal-pathspecs).
But you would not want to feed it to git-log like:
git --literal-pathspecs log $(git ls-files -s | sed ...)
because you'd really want to expand the set of paths at each commit, not
once based on the current index (i.e., it would fail to match paths that
were removed or changed modes).
This is kind of a subtle and esoteric point, but it makes me more
convinced that having powerful pathspec selectors is potentially useful.
Or at least solving a problem that's hard to otherwise solve correctly. :)
-Peff