I had a stupid bug in another series of mine[1] breaking code around git_prompt() in bisect--helper.c, and in trying to follow-up to add testing to that discovered that doing so was rather hard, due to how git_prompt() behaves. In another case in 2019 (which is the In-Reply-To here) we added a seeming for-the-tests workaround for the same issue in "git am --interacive". This starts out by splitting the more complex "get a password interactively" case out of prompt.c into a new prompt-password.c, most of prompt.c's complexity was to cater to one API user in credential.c. That being done move these callers to using git_prompt(), and have it understanda a new GIT_TEST_TERMINAL_PROMPT=true variable so we can have our cake and it it too in the test suite. If that's set the prompt function will allow input on stdin. This then allowed my to add the missing test for "git bisect" for the code I'd accidentally broken in [1]. As noted in the discussion in 2/2 I'm not 100% sure this is the right direction in terms of swiching us back to using /dev/tty and not stdin, but see that commit & commit message for details. In any case, whatever behavior we go for as far as the UX goes shouldn't be catering only to the test suite at the cost of trade-offs elsewhere. 1. https://lore.kernel.org/git/cover-v6-0.8-00000000000-20211102T122507Z-avarab@xxxxxxxxx/ Ævar Arnfjörð Bjarmason (2): prompt.c: split up the password and non-password handling prompt.c: add and use a GIT_TEST_TERMINAL_PROMPT=true Makefile | 1 + builtin/am.c | 8 ++-- builtin/bisect--helper.c | 8 +--- credential.c | 17 ++++---- help.c | 2 +- prompt-password.c | 63 +++++++++++++++++++++++++++++ prompt-password.h | 7 ++++ prompt.c | 79 ++++++++----------------------------- prompt.h | 7 +--- t/t6030-bisect-porcelain.sh | 41 +++++++++++++++++++ t/test-lib.sh | 4 ++ 11 files changed, 151 insertions(+), 86 deletions(-) create mode 100644 prompt-password.c create mode 100644 prompt-password.h -- 2.33.1.1570.g069344fdd45
