On Wed, Nov 03, 2021 at 10:42:14AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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
