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

Johannes Schindelin [off-list ref] writes:

quoted

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.