Steffen Nurpmeso <stef...@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).