Re: [PATCH v2 4/4] allow recovery from command name typos

From: Jeff King <peff@peff.net>
Date: Jul 26, 2012, 17:26 UTC
Message-ID: <20120726172630.GD13942@sigill.intra.peff.net>
In-Reply-To: <CALUzUxp91zubHEkWMC1z2xp7kJCRYrtznQS_=pVSZoNkZMihig@mail.gmail.com>

On Fri, Jul 27, 2012 at 01:08:34AM +0800, Tay Ray Chuan wrote:

Show 8 quoted lines

> > Perhaps we should audit "isatty()" calls and replace them with a
> > helper function that does this kind of thing consistently in a more
> > robust way (my recent favorite is Linus's somewhat anal logic used
> > in builtin/merge.c::default_edit_option()).
> 
> Any specific callers to isatty() you have in mind? A quick grep shows
> that a significant portion of the "offenders" are isatty(2) calls to
> determine whether to display progress, I think those are ok.

Yeah, those are probably fine. Grep reveals that besides isatty(2) and the merge default_edit_option check, we have:

  - isatty(1) for checking auto-output munging, including auto-colors,
    auto-columns, and the pager. These are all fine, as they are not
    about interactivity, but specifically about whether stdout is a tty.

  - isatty(0) in commit.c to print a message when reading "-F -" from
    stdin. OK.

  - isatty(0) in pack-redundant to avoid reading stdin when it is a
    terminal (a questionable choice, perhaps, but not really something
    that would want a full interactivity check).

  - isatty(0) check in cmd_revert to set opts.edit automatically. This
    one should match merge's behavior.

  - isatty(0) in shortlog; this is a compatibility hack as shortlog
    traditionally accepted log output on stdin, but can now be used
    stand-alone. OK.

So I think the only one that could be improved is the one in cmd_revert.

Show 6 quoted lines

> The credential helper has some prompting functionality that is close
> to what I intend to do here, but I think it can make some assumptions
> about stdin/stdout that we can't, as you have pointed out. So that
> leaves merge-edit and this patch as the beneficiaries of a
> builtin/merge.c::default_edit_option() refactor. That's just off the
> top of my head.

The credential code uses git_terminal_prompt, which actually opens /dev/tty directly. So it is probably sane to use for your new prompt, but it does not (and should not) rely on isatty.

> Perhaps the helper function could be named "git_can_prompt()" and
> placed in prompt.c?

Please don't. The isatty() checks have nothing to do with whether git_prompt can run. The only thing such a git_can_prompt function should do is see if we can open /dev/tty.

The isatty check in merge.c is more about "are we interactive, so that it is sane to run $EDITOR".

-Peff