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

Jeff King [off-list ref] 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 [*].

[Footnote]

* "pack-objects" is an excellent example of a command that takes its
  primary input from the standard input, but is a horrible example
  otherwise, because it probably would not make sense for it to take
  any prompted input.

Hi Junio & Peff,

On Wed, 3 Nov 2021, 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.

I think I remember when we talked about this, it was in the context of
`git add -p` becoming a built-in, and we all agreed that it is actually a
very nice side effect that you can feed commands to `git add -p` in
scripts via stdin, not only for testing.

It might have been in the context of another command, but even then it is
a fact that this is a very nice side effect.

Ciao,
Dscho

On Thu, Nov 04, 2021 at 09:48:35AM +0100, Johannes Schindelin wrote:

Hi Junio & Peff,

On Wed, 3 Nov 2021, Junio C Hamano wrote:

quoted

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.

I think I remember when we talked about this, it was in the context of
`git add -p` becoming a built-in, and we all agreed that it is actually a
very nice side effect that you can feed commands to `git add -p` in
scripts via stdin, not only for testing.

It might have been in the context of another command, but even then it is
a fact that this is a very nice side effect.

Yes, we definitely had that discussion about "add -p", and I agree it is
nice. People are probably less likely to drive other tools like git-am
and git-bisect in such a way, though, as their interactive modes just do
a lot less.

-Peff

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