Re: [PATCH] ls-files: add an --exclude-links option

>
> Guido Martínez <mtzguido@gmail.com> 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.