Re: Request feature: –no-submodule

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 04, 2021 at 06:54:10AM +0900, Junio C Hamano wrote:

> > 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. <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.

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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux