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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Nov 03 2021, Jeff King wrote:

> On Tue, Nov 02, 2021 at 05:48:10PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> In 97387c8bdd9 (am: read interactive input from stdin, 2019-05-20) we
>> we fixed a behavior change in the conversion of git-am from a
>> shellscript to a C program by changing it from using git_prompt() to
>> using fgets(..., stdin). This ensured that we could run:
>> 
>>     echo y | git am --interactive [...]
>> 
>> But along with that in the subsequent 6e7baf246a2 (am: drop tty
>> requirement for --interactive, 2019-05-20) we had to remove support
>> for:
>> 
>>     git am --interactive </dev/null
>> 
>> This change builds on the refactoring of git_prompt() into "normal
>> prompt" and "wants password" functions in the preceding commit, and
>> moves "git am --interactive" back to using the prompt function.
>
> Why do we want to do that? The only reason I mentioned that "/dev/null"
> thing in the earlier commit is that it's pointless.
>
> IMHO nothing should be using git_prompt() outside of the credential
> code. They should just be reading from stdin, which is much more
> flexible. If a caller knows that stdin is coming from elsewhere, they
> can redirect from /dev/tty.
>
>> It seems to me that using /dev/tty is desirable over using stdin,
>> these prompts are meant to be interactive, and our acceptance of stdin
>> was an artifact of how these commands were originally implemented in
>> shellscript.
>
> 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.

I'm fine with it either way, my reading of your 2019-ish commits was
that you did that not to intentionally get that behavior, but to work
around that test issue.

So we do always want the "read from stdin" behavior, so I can get those
bisect tests by just changing its behavior too, with no need for the
test variable? If so I'm fine with that.

I think it's a good thing in general to have a not-for-password
git_prompt() API, because it makes it easy to make that use some
readline-like API, i.e. one that would have tab completion, and handle
the loop some (but not all) callers have around handling retries etc,
we'd also be able to translate the "Y" "n" characters...