From: Jonathan Nieder <jrnieder@gmail.com>
To: "Martin Ågren" <martin.agren@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 14:36:28 -0700 [thread overview]
Message-ID: <20180313213628.GB147135@aiede.svl.corp.google.com> (raw)
In-Reply-To: <CAN0heSoP1oVWH0YAFNcL5LG_K7TsmKMAHUA_TiDacVdPtWjTZw@mail.gmail.com>
Martin Ågren wrote:
> On 13 March 2018 at 20:56, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> 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.
Ah, I think I see what I was missing. Let me look again at the whole
paragraph in context:
[...]
>>> Disallow left-over arguments when run from outside a repo. Another
>>> approach would be to disallow them when reading from stdin. However, our
>>> logic is currently the other way round: we check the number of revisions
>>> in order to decide whether we should read from stdin. (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.)
How about something like this?
Disallow left-over arguments when run from outside a repo. This
way, such invalid usage is diagnosed correctly:
$ git shortlog v2.16.0..
error: [...]
[...]
while still permitting the piped form:
$ git -C ~/src/git log --pretty=short | git shortlog
A Large Angry SCM (15):
[...]
This cannot catch an incorrect usage that combines the piped and
<revs> forms:
$ git log --pretty=short | git shortlog v2.16.0..
Alban Gruin (1)
[...]
but (1) the operating system does not provide a straightforward
way to detect that and (2) at least it doesn't crash.
That detail is mostly irrelevant to what the patch does, though. I
wouldn't expect git to be able to diagnose that third variant anyway.
If we want to make the command less error-prone, I think a good path
forward would be to introduce an explicit --stdin option. So I'd be
tempted to go with the short and sweet:
Disallow left-over arguments when run from outside a repo.
[...]
>>> + 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...
[...]
> 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.
Ah, thanks. That makes sense.
>> 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.
Sounds good to me.
Thanks,
Jonathan
next prev parent reply other threads:[~2018-03-13 21:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-10 11:52 [PATCH 0/3] shortlog: do not accept revisions when run outside repo 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
2018-03-13 21:36 ` Jonathan Nieder [this message]
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-05-10 7:11 ` Jeff King
2018-04-19 1:25 ` brian m. carlson
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=20180313213628.GB147135@aiede.svl.corp.google.com \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=martin.agren@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
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).