From: "Kristoffer Haugsbakk" <code@khaugsbakk.name>
To: git@vger.kernel.org
Cc: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: range-diff: slight usability problem with mistyped ref
Date: Sat, 25 Mar 2023 11:04:12 +0100 [thread overview]
Message-ID: <b93934a2-91e7-4645-9a24-4f2354172f31@app.fastmail.com> (raw)
I was using `git range-diff`:[1]
$ git range-diff main feature-v2 HEAD
And got an error message:
fatal: need two commit ranges
I intended to give three arguments to the command. I started to wonder
if I maybe had just typed `main feature-v2` (forgot the third
argument). No, it was three arguments.
The problem was that I had mistyped one argument; it was `feature-v3`,
not `feature-v2`.
I thought that this error message was a little misleading or too
generic. I looked at the history of the file (`builtin/range-diff.c`)
and saw this commit: b75747829f (range-diff: optionally accept
pathspecs, 2022-08-26).
Maybe it works better with a `pathspec` marker (`--`)?
$ git range-diff HEAD main feature-v2 --
fatal: not a revision: 'feature-v2'
usage: git range-diff [<options>] <old-base>..<old-tip> <new-base>..<new-tip>
or: git range-diff [<options>] <old-tip>...<new-tip>
or: git range-diff [<options>] <base> <old-tip> <new-tip>
Yes it does: `not a revision: 'feature-v2'`.
So I tried to contrast the behavior on the current release with the
behavior on the release before the aforementioned commit.
$ git checkout v2.40.0
$ make clean
$ NO_CURL=true make -j 4
$ # Misspelled ref `seen` as `seent`
$ ./bin-wrappers/git range-diff master next seent
fatal: need two commit ranges
usage: git range-diff [<options>] <old-base>..<old-tip> <new-base>..<new-tip>
or: git range-diff [<options>] <old-tip>...<new-tip>
or: git range-diff [<options>] <base> <old-tip> <new-tip>
[…]
Expected behavior: tell me that `seent` is not a revision.
Actual behavior: generic error message.
But I get a nice error message if I append `--`:
$ ./bin-wrappers/git range-diff master next seent --
fatal: not a revision: 'seent'
usage: git range-diff [<options>] <old-base>..<old-tip> <new-base>..<new-tip>
or: git range-diff [<options>] <old-tip>...<new-tip>
or: git range-diff [<options>] <base> <old-tip> <new-tip>
Contrast the behavior on `v2.37.2`, which is one of the tags before
rev. b75747829f (range-diff: optionally accept pathspecs,
2022-08-26).
$ git checkout v2.37.2
$ make clean
$ NO_CURL=true make -j 4
$ ./bin-wrappers/git range-diff master next seent
fatal: not a revision: 'seent'
usage: git range-diff [<options>] <old-base>..<old-tip> <new-base>..<new-tip>
or: git range-diff [<options>] <old-tip>...<new-tip>
or: git range-diff [<options>] <base> <old-tip> <new-tip>
[…]
$ # Tag before rev. b75747829f (range-diff: optionally
$ # accept pathspecs, 2022-08-26)
$ git checkout v2.37.2
$ ./bin-wrappers/git range-diff HEAD master seent
fatal: ambiguous argument 'HEAD..seent': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
error: could not parse log for 'HEAD..seent'
This error message is exactly what I expect to see when I mistype a ref
(my git(1) conditioning).
But the `v2.40.0` error message with `--` is better: `fatal: not a
revision: 'seent'`.
So what if I give a `--`:
$ # Still on v2.37.2
$ ./bin-wrappers/git range-diff master next seent --
fatal: ambiguous argument 'master..seent': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
error: could not parse log for 'master..seent'
It’s the same. Oh, right—I guess rev. b75747829f taught `range-diff`
about `--`.
In conclusion: IMO and assuming that my cross-version testing is
correct, `range-diff` has a slight usability regression for when you
mistype the ref. It would be nice if the error message without a
pathspec separator (`--`/`dash_dash`) was as nice as the one without it.
[1]: Original thread: https://groups.google.com/g/git-users/c/O5uB-E68S_0
--
Kristoffer Haugsbakk
next reply other threads:[~2023-03-25 10:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-25 10:04 Kristoffer Haugsbakk [this message]
2023-03-28 11:37 ` range-diff: slight usability problem with mistyped ref Johannes Schindelin
2023-04-03 19:29 ` Kristoffer Haugsbakk
2023-04-04 20:20 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b93934a2-91e7-4645-9a24-4f2354172f31@app.fastmail.com \
--to=code@khaugsbakk.name \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).