Hi Junio, > Date: 2026-11-06 12:16:48-0800 > From: Junio C Hamano > > Alejandro Colomar writes: > > >> > With -z it becomes a bit tedious: > >> > > >> > $ git ls-files -z --format='%(objectmode) %(path)' \ > >> > | grep -zv ^120000 \ > >> > | sed -z 's/^.* //' \ > >> > | grep -z '\.[ch]$' \ > >> > | xargs -0 grepc creat; > > Shouldn't the grep|sed|grep be doable with a single sed invocation? > > >> > I expect git-ls-files(1) could make this much simpler, though: > >> > > >> > $ git ls-files --type f \ > >> > | grep '\.[ch]$' \ > >> > | xargs grepc creat; > > Not really. Why is "--type" have to be so special? What would the > next person ask for? --size? Indeed. While looking at the implementation of git-ls-files(1), I realized it wasn't easy to decide how to implement this, as it has other types (objecttype, which is blob/commit/...). I thought perhaps --objectmode, but then I'm not inderested in searching specific modes, but rather filtering out some. Perhaps in this case it's more appropriate to have my own local command 'git-find' that does what I want. I've ended up doing this, and now don't think a flag in git-ls-files(1) would make much sense. $ cat $(which git-find) #!/bin/bash # Copyright 2026, Alejandro Colomar # SPDX-License-Identifier: GPL-3.0-or-later set -Eeufo pipefail; git ls-files --format='%(objectmode) %(path)' \ | grep -v '^120000' \ | sed 's/^.* //'; And will eventually add a -z flag for this command when I find I need it. > The "ls-files" plumbing command is designed as a component to build > your own pipeline with. Don't throw in random unrelated features to > it. In the longer run, it is not a good substitute for improving > the skill to construct a good pipeline. Indeed. > Learn the tools available to you that you already have heard of, so > that you can make better uses of them (in this case "sed"). If you > squash the grep|sed|grep pipeline into a single sed > > git ls-files -z -s "*.[ch]" | > sed -z -n -e '/^120000/d' -e '/^.* 0 /s///p' | > xargs -r -0 ls -ld > > the result does not look too bad. I find it simpler to have a simple grep -v rejecting the lines I don't want, and then sed(1) getting rid of the stuff. The command above seems interesting for performance, but compared to the tool using the file names, that's probably negligible. About git-ls-files(1)'s -s, I think it's easier to parse with the %(objectmode) in the format, as I don't need all the other information printed by -s. > > One unrelated tip for better readability is to end, not begin, your > lines with the "|" pipe characters. That way you do not have to > sprinkle so many unsightly backslashes ;-). I like to have them at the front of the line because it shows more clearly whether I'm piping a command or starting a new pipeline. I got used to the backslashes. After all, the first few characters of a line are all aligned, and the most significant ones. Stuff to the right I tend to ignore it as noise. :) > > HTH. Yup! Thanks! Have a lovely night! Alex --