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