Re: Silly 'git am' UI issue

[Junio C Hamano <gitster@pobox.com>]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> So what happens is that "git am" decides that <filename> is the
> argument to the "--whitespace" option, then doesn't see an argument at
> all, and expects the input from stdin. So it "hangs", waiting for
> input. No error messages, no nothing.

Ouch.  I suspect there are other (e.g. "pull -> fetch") passthru
that share similar issues, but "am" may be quite special in that
it is prepared to read its input from the standard input stream.

I wonder if something like this would have helped.

----- >8 --------- >8 --------- >8 --------- >8 --------- >8 -----
Subject: am/apply: warn if we end up reading patches from terminal

In an interactive session, "git am" without arguments, or even
worse, "git am --whitespace file", waits silently for the user to
feed the patches from the standard input (presumably by typing or
copy-pasting).  Give a feedback message to the user when this
happens, as it is unlikely that the user meant to do so.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin/mailsplit.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git c/builtin/mailsplit.c w/builtin/mailsplit.c
index 7baef30569..c45f542341 100644
--- c/builtin/mailsplit.c
+++ w/builtin/mailsplit.c
@@ -223,6 +223,9 @@ static int split_mbox(const char *file, const char *dir, int allow_bare,
 	FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "r");
 	int file_done = 0;
 
+	if (isatty(fileno(f)))
+		warning(_("reading patches from stdin/tty..."));
+
 	if (!f) {
 		error_errno("cannot open mbox %s", file);
 		goto out;