Web lists-archives.com

Re: No clear API/Error message to validate a "revision object" using git rev-parse

On Tue, Jan 29, 2019 at 12:51 PM Christian Couder
<christian.couder@xxxxxxxxx> wrote:
> > `--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 ...
'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,
Ντέντος Σταύρος