Hello,
Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote:
|Steffen Nurpmeso venit, vidit, dixit 22.09.2016 00:46:
|> Junio C Hamano <gitster@xxxxxxxxx> wrote:
|>|Steffen Nurpmeso <steffen@xxxxxxxxxx> 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