Michael J Gruber <g...@drmicha.warpmail.net> wrote:
 |Steffen Nurpmeso venit, vidit, dixit 22.09.2016 00:46:
 |> Junio C Hamano <gits...@pobox.com> wrote:
 |>|Steffen Nurpmeso <stef...@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

      Suppress all output; instead exit with zero status if <object>
      exists and is a valid object.
    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.


Reply via email to