* v2.10.0: ls-tree exit status is always 0, this differs from ls(1) @ 2016-09-21 13:26 Steffen Nurpmeso 2016-09-21 16:52 ` Junio C Hamano 0 siblings, 1 reply; 7+ messages in thread From: Steffen Nurpmeso @ 2016-09-21 13:26 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1) 2016-09-21 13:26 v2.10.0: ls-tree exit status is always 0, this differs from ls(1) Steffen Nurpmeso @ 2016-09-21 16:52 ` Junio C Hamano 2016-09-21 19:40 ` Steffen Nurpmeso 0 siblings, 1 reply; 7+ messages in thread From: Junio C Hamano @ 2016-09-21 16:52 UTC (permalink / raw) To: Steffen Nurpmeso; +Cc: git 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1) 2016-09-21 16:52 ` Junio C Hamano @ 2016-09-21 19:40 ` Steffen Nurpmeso 2016-09-21 20:39 ` Junio C Hamano 0 siblings, 1 reply; 7+ messages in thread From: Steffen Nurpmeso @ 2016-09-21 19:40 UTC (permalink / raw) To: Junio C Hamano; +Cc: git [-- 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>:: ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1) 2016-09-21 19:40 ` Steffen Nurpmeso @ 2016-09-21 20:39 ` Junio C Hamano 2016-09-21 22:46 ` Steffen Nurpmeso 0 siblings, 1 reply; 7+ messages in thread From: Junio C Hamano @ 2016-09-21 20:39 UTC (permalink / raw) To: Steffen Nurpmeso; +Cc: git 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). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1) 2016-09-21 20:39 ` Junio C Hamano @ 2016-09-21 22:46 ` Steffen Nurpmeso 2016-09-22 11:36 ` Michael J Gruber 0 siblings, 1 reply; 7+ messages in thread From: Steffen Nurpmeso @ 2016-09-21 22:46 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1) 2016-09-21 22:46 ` Steffen Nurpmeso @ 2016-09-22 11:36 ` Michael J Gruber 2016-09-22 12:57 ` Steffen Nurpmeso 0 siblings, 1 reply; 7+ messages in thread From: Michael J Gruber @ 2016-09-22 11:36 UTC (permalink / raw) To: Steffen Nurpmeso, Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1) 2016-09-22 11:36 ` Michael J Gruber @ 2016-09-22 12:57 ` Steffen Nurpmeso 0 siblings, 0 replies; 7+ messages in thread From: Steffen Nurpmeso @ 2016-09-22 12:57 UTC (permalink / raw) To: Michael J Gruber; +Cc: git, Junio C Hamano 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-09-22 12:56 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-09-21 13:26 v2.10.0: ls-tree exit status is always 0, this differs from ls(1) Steffen Nurpmeso 2016-09-21 16:52 ` Junio C Hamano 2016-09-21 19:40 ` Steffen Nurpmeso 2016-09-21 20:39 ` Junio C Hamano 2016-09-21 22:46 ` Steffen Nurpmeso 2016-09-22 11:36 ` Michael J Gruber 2016-09-22 12:57 ` Steffen Nurpmeso
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.