Re: [PATCH v4] add-patch: response to unknown command

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

Rubén Justo <rjusto@gmail.com> writes:

> The current options are:
>
> 	a.- make the test check for stderr and stdout, separatedly

There is a downside that we do not check what the users would see,
as I mentioned in an earlier message.

> 	b.- fflush(stdout) in err
>
> 	c.- make err print to stdout

Yup.  The last one is what I showed in the thread.

> I suspect that similar tests for other commands would produce similar
> errors, so (a) seems like an easy fix but feels like kicking the can
> forward.
>
> I'm not sure of the implications of (c).  Perhaps moving current
> messages to stdout breaks some workflow out there?  The other thread
> about disabling all hints has made me think.

That depends on "other" commands.  As Phillip said, "git add -p" and
the like that interacts with the end user via terminal, using a
single stream, whether it is the standard error stream or the
standard output stream, should not affect any end-user experience.
It is very unlikely people capture only one stream and feed it to a
program, and with i18n, these messages are not even designed for
machine consumption in the first place.

> The (b) option seems to me the less disturbing change

Sticking close to the status quo would certainly _feel_ the safest
at least in the shorter term.

But given that there is not really a reasonable justification why
some output goes to the standard output stream while others go to
the standard error stream in this program (note that I am
specifically talking about the terminal interactive session with
"add -p"), the approach will force us to worry about similar gotchas
and we need to decide which stream the message needs to go every
time we add a new one.

> but it has not attracted attention.

I think the same reasoning from the old thread that made us avoid
the "flush() and keep writing to two streams" in the worktree code
would apply here, too.