Re: [PATCH 2/2] prompt.c: add and use a GIT_TEST_TERMINAL_PROMPT=true

From: Jeff King <peff@peff.net>
Date: Nov 4, 2021, 09:53 UTC
Message-ID: <YYOttuoQT2X6HC/C@coredump.intra.peff.net>
In-Reply-To: <xmqqo8716sqx.fsf@gitster.g>

On Wed, Nov 03, 2021 at 10:42:14AM -0700, Junio C Hamano wrote:

Show 17 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > Basically, I think I just disagree with this paragraph entirely. Moving
> > to stdin in the commits you referenced was done to help testing, but I
> > also think it's just a more flexible direction overall.
> 
> It is OK, and it is more convenient for writing test scripts, to
> take interactive input from the standard input stream, if the
> command does not use the standard input for other purposes.
> 
> "git am -i <mbox" cannot take prompted input via the standard input,
> but "git am -i mbox" is an easy workaround, for example.
> 
> Commands that are designed to be used in the downstream of a pipe
> (e.g. "git rev-list ... | git pack-objects") cannot easily use such
> a workaround, so they may still need to open and interact with
> /dev/tty if they want to do an interactive input, though [*].

True. The most Unix-y thing there would be to provide an option for reading interactive input from an arbitrary descriptor. That gives the most flexibility, though it's probably a bit arcane for most folks to do:

  git foo | git bar --interactive-from=3 3</dev/tty

We could directly allow:

  git foo | git bar --interactive-from=/dev/tty

which is a bit less arcane. Or alternatively this could come from the environment, like:

  export GIT_INTERACTIVE_FROM=/dev/tty
  git foo | git bar --interactive

Which is equivalent-ish to having a boolean env variable to say "read from the terminal", except that it retains some more of the flexibility (especially if we treat a numeric value as a descriptor).

Of course yet another option is to teach commands like pack-objects that read input only from stdin to accept a command-line option to read that input from a file. Then stdin is free for interactive use. ;)

But I would not do any of that until we had a command that was a good candidate. In the case of git-am and git-bisect, I think it's fine to assume that "-i" will use stdin.

-Peff