Rubén Justo <rjusto@xxxxxxxxx> 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.
