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

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

[Steffen Nurpmeso]

I think this behaviour contradicts the manual which strongly links
ls-tree to ls(1):

  ?0[steffen@wales ]$ ls NEWSS
  ls: cannot access 'NEWSS': No such file or directory
  ?2[steffen@wales ]$ git ls-tree --name-only master NEWSS                                                                                       
  ?0[steffen@wales ]$ ls NEWS                                                                                                                    
  NEWS
  ?0[steffen@wales ]$ git ls-tree --name-only master NEWS                                                                                        
  NEWS
  ?0[steffen@wales ]$ 

Ciao.

--steffen

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

[Junio C Hamano]

Steffen Nurpmeso <steffen@sdaoden.eu> writes:

> I think this behaviour contradicts the manual which strongly links
> ls-tree to ls(1):

Patches to the documentation is very much welcomed.

Somewhere the similarity must end, and actually it ends a lot
earlier, as "/bin/ls" takes exact paths while "ls-tree" (or any
other Git command for that matter) takes a pathspec pattern,
and not having a path that matches the pathspec pattern is not
an error condition.

Thanks.

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

[Steffen Nurpmeso]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

Hello.

Junio C Hamano <gitster@pobox.com> wrote:
 |Steffen Nurpmeso <steffen@sdaoden.eu> writes:
 |> I think this behaviour contradicts the manual which strongly links
 |> ls-tree to ls(1):
 |
 |Patches to the documentation is very much welcomed.

The below could serve this purpose.

 |Somewhere the similarity must end, and actually it ends a lot
 |earlier, as "/bin/ls" takes exact paths while "ls-tree" (or any
 |other Git command for that matter) takes a pathspec pattern,
 |and not having a path that matches the pathspec pattern is not
 |an error condition.

I was just surprised to see nothing and get no feedback at all.
Ciao!

--steffen

[-- Attachment #2: git-ls-tree-doc.diff --]
[-- Type: text/x-diff, Size: 539 bytes --]

diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index dbc91f9..8ebeced 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -33,6 +33,10 @@ in the current working directory.  Note that:
    However, the current working directory can be ignored by passing
    --full-tree option.
 
+ - the behaviour is different to that of "/bin/ls" in sofar as non-existing
+   '<path>' arguments are silently ignored and not reflected in the exit
+   status code.
+
 OPTIONS
 -------
 <tree-ish>::

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

[Junio C Hamano]

Steffen Nurpmeso <steffen@sdaoden.eu> writes:

> diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
> index dbc91f9..8ebeced 100644
> --- a/Documentation/git-ls-tree.txt
> +++ b/Documentation/git-ls-tree.txt
> @@ -33,6 +33,10 @@ in the current working directory.  Note that:
>     However, the current working directory can be ignored by passing
>     --full-tree option.
>  
> + - the behaviour is different to that of "/bin/ls" in sofar as non-existing
> +   '<path>' arguments are silently ignored and not reflected in the exit
> +   status code.
> +
>  OPTIONS
>  -------
>  <tree-ish>::

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:

    Note that:

     - the behaviour is slightly different from that of "/bin/ls" in that the
       '<path>' denotes just a list of patterns to match, e.g. so specifying
       directory name (without `-r`) will behave differently, and order of the
       arguments does not matter.

     - the behaviour is similar to that of "/bin/ls" in that the '<path>' is
       taken as relative to the current working directory.  E.g. when you are
       in a directory 'sub' that has a directory 'dir', you can run 'git
       ls-tree -r HEAD dir' to list the contents of the tree (that is
       'sub/dir' in `HEAD`).  You don't want to give a tree that is not at the
       root level (e.g. `git ls-tree -r HEAD:sub dir`) in this case, as that
       would result in asking for 'sub/sub/dir' in the `HEAD` commit.
       However, the current working directory can be ignored by passing
       --full-tree option.

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

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

[Steffen Nurpmeso]

Junio C Hamano <gitster@pobox.com> wrote:
 |Steffen Nurpmeso <steffen@sdaoden.eu> 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,

--steffen

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

[Michael J Gruber]

Steffen Nurpmeso venit, vidit, dixit 22.09.2016 00:46:
> Junio C Hamano <gitster@pobox.com> wrote:
>  |Steffen Nurpmeso <steffen@sdaoden.eu> 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

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

[Steffen Nurpmeso]

Hello,

Michael J Gruber <git@drmicha.warpmail.net> wrote:
 |Steffen Nurpmeso venit, vidit, dixit 22.09.2016 00:46:
 |> Junio C Hamano <gitster@pobox.com> wrote:
 |>|Steffen Nurpmeso <steffen@sdaoden.eu> writes:
 ...
 |>|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
 ...
 |>|How about rewriting the first bullet point like so instead:
 ...
 |>|    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:
 ...

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

Please rollback all of that, i have only reported something that
seemed odd to me.  What i really need is instead

  if `git cat-file -e ${relbr}:NEWS 2>/dev/null`; then

and that is what i will end up with.
_But_, now that i am here again, "git help cat-file" says

  -e
      Suppress all output; instead exit with zero status if <object>
      exists and is a valid object.
and
  OUTPUT
...
    If -e is specified, no output.

But this is not what happens if "output" includes stderr:

  ?0[steffen@wales ]$ git cat-file -e HEAD:NEWS                                                                                                
  ?0[steffen@wales ]$ git cat-file -e HEAD:NEWSS                                                                                                 
  fatal: Not a valid object name HEAD:NEWSS
  ?128[steffen@wales ]$ 

I would also not expect $?=128 as an counterpart to EXIT_SUCCESS=0
when performing a qualified "test" action, but EXIT_FAILURE=1 is
just an as-bad non-0 exit status code, anyway.  To me
EX_NOINPUT=66 obtrudes itself as the right status, but my own
projects don't adhere to this from a-z or not at all, so what i am
talking about?  I mean, some things take time and are eventually
and temporarily a bit odd, so what?  That is just how it is.  Even
Sparta declined some day, and then it crushed, iirc.

Thanks for git, just yesterday evening i did rebasing and cherry
picking and commit amending and garbage collection and it saved me
days of work, or, to be more exact, i never have been able to work
the way i would work before.  Really.
Ciao.

--steffen