Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1)

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

 



Steffen Nurpmeso venit, vidit, dixit 22.09.2016 00:46:
> Junio C Hamano <gitster@xxxxxxxxx> wrote:
>  |Steffen Nurpmeso <steffen@xxxxxxxxxx> writes:
>  ...
>  |Sorry, but I did not notice that there was an attached patch when I
>  |was reading your response for the first time.  Risk of using an
>  |attachment to e-mail ;-)
>  |
>  |I think this issue does not need a separate bullet point.  The
>  |existing text says:
>  ..
>  |and what caused your surprise is already covered by the first bullet
>  |point, if the reader knows what "patterns to match" means in Git's
>  |command line tools; it just needs to be extended to be more
>  |meaningful to those who don't, I think.
>  |
>  |How about rewriting the first bullet point like so instead:
>  |
>  |  - the behaviour is different from that of "/bin/ls" in that the
>  |    '<path>' are actually patterns to match, e.g. so specifying
>  |    directory name (without `-r`) will behave differently, the order
>  |    of the arguments does not matter, and a '<path>' argument that
>  |    does not match any path is not an error (i.e. if there is no
>  |    path that matches any pattern, nothing is shown in the output).
> 
> Not an error would have been an enlightenment to me.
> 
> But now i'm even getting nervous to read about patterns.
> We have patterns for tags/remotes/branches, author/committer/grep
> patterns, (most of those, maybe all today, with fixed string,
> extended or basic regex), the git-grep patterns ("leading paths
> match and glob(7) patterns are supported").  Is that all?
> I would assume glob-style for ls-tree:
> 
>   ?0[steffen@wales ]$ git ls-tree HEAD `ls mime*`
>   100644 blob ee47419c209da789b606ab6d979c22f4ae632712    mime.c
>   100644 blob 0cfe3766bd5f035eac06b728a4f63224455e13ca    mime.types
>   100644 blob 7d890df7553522691ed09f266ea7f9effb6a2f4e    mime_enc.c
>   100644 blob 430e300d9a8887c5cd48d1cc63034168e47e9721    mime_param.c
>   100644 blob 0338a46d3247ea00b5bcedb2d82ff30fe5d18d48    mime_parse.c
>   100644 blob d62fa8defae27240a5ce81ad2239dd7f94b6c5c5    mime_types.c
>   ?0[steffen@wales ]$ git ls-tree HEAD 'mime*'
>   ?0[steffen@wales ]$ git ls-tree HEAD 'mime.*'
> 
> No, ls-tree is not part of what i use every day, "Git's command
> line tools" is (too) wide afield, in that sense.
> 
> Thank you (also in general, for git), and ciao from a country with
> a pretty real autumn,

Maybe "git ls-files" is the command that you are looking for, really.

That and others have glob pathspec enabled by default, see "git help git".

"git ls-tree" does not understand globs nor pathspec magic. In fact, it
only matches on the first component of a path (complete matches).

Michael




[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]