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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 26, 2024, 05:39 UTC
Message-ID: <xmqqwmokbs3p.fsf@gitster.g>
In-Reply-To: <305296f1-975b-41b9-968c-3984d8056196@gmail.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.

Show 7 quoted lines

> 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.