Subject: Re: [PATCH v5 14/16] merge-recursive: offer an option to retain the output in 'obuf'

From: Junio C Hamano <[email-masked]>
Date: Tue, 02 Aug 2016 14:19:45 -0700

Johannes Schindelin <[email-masked]> writes:

>> But in that case, there would be both messages meant for the
>> standard output and also meant for the standard error, and we need
>> some way to make sure they go to the right channel.
>
> Not necessarily. Let's have a look at our existing code in
> git-rebase.sh:
>
> 	output () {
> 		case "$verbose" in
> 		'')
> 			output=$("$@" 2>&1 )
> 			status=$?
> 			test $status != 0 && printf "%s\n" "$output"
> 			return $status
> 			;;
> 		*)
> 			"$@"
> 			;;
> 		esac
> 	}
>
> This incredibly well-named function (</sarcasm>, my fault: dfa49f3 (Shut "git
> rebase -i" up when no --verbose was given, 2007-07-23)) accumulates all
> output, both stdout and stderr, and shows it only in case of an error.
>
> Crucially, *all* output goes to stdout. No distinction is being made
> between stdout and stderr.

> ...
> This is the existing behavior of rebase -i.
> ...
> As such, it would be a serious mistake to implement that mode and use it
> in the rebase--helper: it would very likely cause regressions in existing
> scripts, probably even my own.

Sounds like we are desperately trying to find an excuse to do a
wrong thing by finding an existing piece of code that did a wrong
thing already.

That leaves a bad taste in my mouth, but as "rebase -i" is meant to
be an "interactive" command, I would imagine that nobody would have
expected to run it as "git rebase -i >/dev/null" in order to view
only the error messages (or vice versa with "2>errs").

So OK then, at least for now.