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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 2, 2016, 21:19 UTC
Message-ID: <xmqq60ridg26.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1608020948220.79248@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 27 quoted lines

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

Show 6 quoted lines

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