git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Martin Ågren <martin.agren@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 3/3] shortlog: do not accept revisions when run outside repo
Date: Tue, 13 Mar 2018 21:47:28 +0100
Message-ID: <CAN0heSoP1oVWH0YAFNcL5LG_K7TsmKMAHUA_TiDacVdPtWjTZw@mail.gmail.com> (raw)
In-Reply-To: <20180313195640.GA147135@aiede.svl.corp.google.com>

On 13 March 2018 at 20:56, Jonathan Nieder <jrnieder@gmail.com> 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

  reply index

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-10 11:52 [PATCH 0/3] " Martin Ågren
2018-03-10 11:52 ` [PATCH 1/3] git-shortlog.txt: reorder usages Martin Ågren
2018-03-13 19:19   ` Junio C Hamano
2018-03-10 11:52 ` [PATCH 2/3] shortlog: add usage-string for stdin-reading Martin Ågren
2018-03-10 11:52 ` [PATCH 3/3] shortlog: do not accept revisions when run outside repo Martin Ågren
2018-03-13 19:56   ` Jonathan Nieder
2018-03-13 20:47     ` Martin Ågren [this message]
2018-03-13 21:36       ` Jonathan Nieder
2018-03-13 21:46   ` Junio C Hamano
2018-03-14  5:06     ` Martin Ågren
2018-03-14 21:34 ` [PATCH v2 0/3] shortlog: disallow left-over arguments " Martin Ågren
2018-03-14 21:34   ` [PATCH v2 1/3] git-shortlog.txt: reorder usages Martin Ågren
2018-03-14 21:34   ` [PATCH v2 2/3] shortlog: add usage-string for stdin-reading Martin Ågren
2018-03-14 21:34   ` [PATCH v2 3/3] shortlog: disallow left-over arguments outside repo Martin Ågren
2018-03-28  8:48 ` [PATCH 0/3] shortlog: do not accept revisions when run " Jeff King
2018-03-28 12:24   ` Martin Ågren
2018-04-17 19:15     ` [PATCH 0/4] doc: cleaning up instances of \-- Martin Ågren
2018-04-17 19:15       ` [PATCH 1/4] doc: convert \--option to --option Martin Ågren
2018-04-17 19:15       ` [PATCH 2/4] doc: convert [\--] to [--] Martin Ågren
2018-04-17 19:15       ` [PATCH 3/4] git-[short]log.txt: unify quoted standalone -- Martin Ågren
2018-04-17 19:15       ` [PATCH 4/4] git-submodule.txt: quote usage in monospace, drop backslash Martin Ågren
2018-04-18  4:24       ` [PATCH 0/4] doc: cleaning up instances of \-- Junio C Hamano
2018-04-19  1:25       ` brian m. carlson

Reply instructions:

You may reply publically 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=CAN0heSoP1oVWH0YAFNcL5LG_K7TsmKMAHUA_TiDacVdPtWjTZw@mail.gmail.com \
    --to=martin.agren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    /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

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox