Guido Martínez <mtzguido@xxxxxxxxx> writes:
> So would it make sense to
> 1- Add the file type filter to ls-files
I think it definitely makes sense to extend the filtering criteria
supported by ls-files beyond what we currently support (i.e.
pathspec).
I also wonder if "file type filter" could just be implemented as the
magic pathspec. For example, we can already use the magic pathspec
'attr' (read on "pathspec" in "git help glossary") this way:
$ git ls-files ":(attr:eol=crlf)"
to list only those files for which the 'eol' attribute is set to
'crlf' (i.e. they must be checked out for DOS no matter what your
platform actually is). That is even more flexible than the
hardcoded "is it a regular file? is it a symlink? is it a
submodule" file types. And the magic pathspec is understood not
everywhere but by git subcommands other than "ls-files".
We can either invent a new pathspec magic "filetype" and express
them this way,
$ git ls-files ":(filetype:regular)" # 100644 and 100755
$ git ls-files ":(filetype:symbolic-link)" # 120000
$ git ls-files ":(filetype:submodule)" # 160000
or we invent a magic attribute "filetype" that is automatically
given to every path, and express the above more like so:
$ git ls-files ":(attr:filetype=regular)" # 100644 and 100755
$ git ls-files ":(attr:filetype=symbolic-link)" # 120000
$ git ls-files ":(attr:filetype=submodule)" # 160000
may be even better, as there are git subcommands other than ls-files
that supports magic pathspec. For example, it might be even useful
to do something like
$ git diff v1.0 v2.0 -- ":(attr:filetype=executable)"
instead of saying
$ git diff v1.0 v2.0 -- \*.sh \*.perl \*.py \*.bat
So, yeah, whether it is done via the magic pathspec or "ls-files"
specific option, teaching "ls-files" to support more filtering
criteria would make sense.
> 2- Use that to implement a proper git-do-for-paths script/binary,
> which can take pathspecs, filetype filters, -n, -P, and maybe more
> ?
The primary obstacle was you'd need a custom perl script to filter
"ls-files -z" output, but once that need is gone, I actually do not
think it buys us a lot to have such a wrapper. Treat the improved
ls-files as what it is, i.e. a plumbing command that can be used as
a building block of your workflow, and piping its output to xargs
would just be fine.
Thanks.
