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

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

Jeff King [off-list ref] writes:

quoted

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