threads / discuss / 50346

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

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

## tl;dr

3 messages between Jan 29, 2019 and Jan 29, 2019.

replies: 2people: 2as markdown or json

Ντέντος Σταύρος· Jan 29, 2019, 09:25 UTC · lore

Hello there everyone,

Minor bug report: I have a utility script to find "reference points" that contain a commit (git-x-in-y)

The script needs to accept "any valid reference point", that includes e.g. tags as well. I validate said input by passing whatever argument through git rev-parse.

If the tag name is invalid, say: $ git rev-parse version.3 version.3 fatal: ambiguous argument 'version.3': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'

So, I follow the recommendation to add '--', since I know that I won't be adding any paths:

$ git rev-parse version.3 -- fatal: bad revision 'version.3'

However, what happens with the correct tags is, I get the trailing double dash in: $ git rev-parse version-0.false -- d43292476ea9ab8c3d32940352b680549b64e8d8 -- $

A further leading argument, e.g. '' makes the situation worse: $ git rev-parse version-0.false -- '' d43292476ea9ab8c3d32940352b680549b64e8d8 --

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

Further attempts do not help either: $ git rev-parse --revs-only version-3 ; echo $? 0 $

Am I writing the command wrong, or is there some part of it I don't understand?

Ntentos Stavros

Christian Couder· Jan 29, 2019, 10:51 UTC · re: Ντέντος Σταύρος · lore

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

Hi,

On Tue, Jan 29, 2019 at 10:30 AM Ντέντος Σταύρος <stdedos@gmail.com> wrote:

Show 12 quoted lines

> So, I follow the recommendation to add '--', since I know that I won't
> be adding any paths:
>
> $ git rev-parse version.3 --
> fatal: bad revision 'version.3'
>
> However, what happens with the correct tags is, I get the trailing
> double dash in:
> $  git rev-parse version-0.false --
> d43292476ea9ab8c3d32940352b680549b64e8d8
> --
> $

Yeah, it looks like a bug to me.

Show 6 quoted lines

> A further leading argument, e.g. '' makes the situation worse:
> $ git rev-parse version-0.false -- ''
> d43292476ea9ab8c3d32940352b680549b64e8d8
> --
>
> $

This also.

> `--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.

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

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.

> $ git rev-parse --verify version-0.false
> 80f20b100cca5166b22cbcc1f4a6ac1eae64a0d0

This also works correctly.

And:

$ git rev-parse --verify v2.2.0 -- 74d2a8cf12bf102a8cedaf66736503bb3fe88dfb $

also works correctly.

Best, Christian.

Ντέντος Σταύρος· Jan 29, 2019, 12:01 UTC · re: Christian Couder · lore

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@gmail.com> wrote:

Show 16 quoted lines

> > `--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, Ντέντος Σταύρος