On Tue, Jan 29, 2019 at 12:51 PM Christian Couder
[off-list ref] wrote:

quoted

`--verify`s error message is even more cryptic:
$ git rev-parse --verify version.3
fatal: Needed a single revision

Yeah, but it works.

The error message could perhaps be improved. On the other hand it has
been the same for a very very long time and very few people complained
about it.

[...]

In fact as `git rev-parse` is a "plumbing command" it's supposed to be
used mostly by scripts and power user who can easily deal with such an
error message, which explains why there has not been much incentive to
change this error message.

I understand the points here, and I understand how minor this "issue"
is in a sense.
Maintainers / fixer can decide on it, but I thought I should bring it
to lists' attention.

As you are writing a script, you can at least easily redirect it to
/dev/null and output something else.

I like the "expected" output in that way, since:

'version.0-false' is not matching. I am asking git ...
80d790c17c9a3f10c156561efc323ac5d4684b16
'version.0' is not matching. I am asking git ... fatal: bad revision 'version.0'

it "complements" the previous output, and sounds "fluent enough".
And also that I don't have to patchwork it (I can, obviously).

The reason I mentioned:

$ git rev-parse --verify version.3
fatal: Needed a single revision

is that the message sounds counter-intuitive. I already gave (what I
thought was) a revision, and it is "already" one.
I "could" claim that `git rev-parse` is reading 2 arguments
(`--verify` and `version.3`),
and somehow `git rev-parse --verify` checks that `argc == 1`, and
failing due to a bug in the code.

I would understand that message in this context:

$ git rev-parse --verify version.3 version.4
fatal: Needed a single revision

since I gave 2 arguments instead of 1.

With regards,
Ντέντος Σταύρος