On 13 March 2018 at 20:56, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Hi,
>
> Martin Ågren wrote:
>
>> (So yes, after
>> this patch, we will still silently ignore stdin for confused usage such
>> as `git log v2.15.0.. | git shortlog v2.16.0..`. But at least that does
>> not crash.)
>
> I don't follow here. Are you saying this command should notice that
> there is input in stdin? How would it notice?
I have no idea how it would notice (portably!) and the gain seems
minimal. I added this to keep the reader from wondering "but wait a
minute, doesn't that mean that we fail to catch this bad usage if we're
in a repo?". So my answer would be "yep, but it's not a huge problem".
Of course, my attempt to pre-emptively answer a question only provoked
another one. :-) I could phrase this better.
>> --- a/builtin/shortlog.c
>> +++ b/builtin/shortlog.c
>> @@ -293,6 +293,12 @@ int cmd_shortlog(int argc, const char **argv, const char *prefix)
>> parse_done:
>> argc = parse_options_end(&ctx);
>>
>> + if (nongit && argc != 1) {
>
> Just curious: would argc ever be 0 here? 'argc <= 1' might be clearer.
Hmm, good point. It "shouldn't" be 0, but I guess it's better to be safe
than sorry. (We seem to have both constructs, in various places.)
>> + error(_("no revisions can be given when running "
>> + "from outside a repository"));
>> + usage_with_options(shortlog_usage, options);
>> + }
>> +
>
> The error message is
>
> error: no revisions can be given when running from outside a repository
> usage: ...
>
> Do we need to dump usage here? I wonder if a simple die() call would
> be easier for the user to act on.
I can see an argument for "dumping the usage makes the error harder than
necessary to find". I mainly went for consistency. This ties into your
other observations below: what little consistency do we have and in
which direction do we want to push it...
> Not about this patch: I was a little surprised to see 'error:' instead
> of 'usage:' or 'fatal:'. It turns out git is pretty inconsistent
> about that: e.g. there is
>
> error(_("no remote specified"));
> usage_with_options(builtin_remote_setbranches_usage, options);
>
> Some other callers just use usage_with_options without describing the
> error.
The other two approaches ("die" and "error and usage") can be argued
for, but this one ("give usage") just seems wrong to me. I haven't
looked for such a place in the code, and maybe they're "obvious", but it
seems odd to just give the usage without any sort of hint about what was
wrong.
> check-attr has a private error_with_usage() helper to implement
> the error() followed by usage_with_options() idiom. Most callers just
> use die(), like
>
> die(_("'%s' cannot be used with %s"), "--merge", "--patch");
>
> Documentation/technical/api-error-handling.txt says
>
> - `usage` is for errors in command line usage. After printing its
> message, it exits with status 129. (See also `usage_with_options`
> in the link:api-parse-options.html[parse-options API].)
>
> which is not prescriptive enough to help.
I think it would be a larger project to make these consistent. The one
I'm adding here is at least consistent with the other one in this file.
> Separate from that, I wonder if the error message can be made a little
> shorter and clearer. E.g.
>
> fatal: shortlog <revs> can only be used inside a git repository
Some grepping suggests we do not usually name the command ("shortlog
..."), perhaps to play well with aliasing, nor do we use "such <syntax>"
very often, but it does happen. Quoting and allowing for options might
make this more correct, but perhaps less readable: "'shortlog [...]
<revs>' can only ...". Slightly better than what I had, "revisions can
only be given inside a git repository" would avoid some negating.
> Thanks and hope that helps,
It does indeed. I'll give this another 24h and see what I come up with.
I believe it will end up in a change to "<= 1", an improved error
message and a clearer last few words in the commit message.
Martin
