Re: [PATCH 5/5] format-patch: avoid freopen()

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 22, 2016, 17:53 UTC
Message-ID: <xmqqpor9m7o4.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1606221811300.10382@virtualbox>

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

Show 6 quoted lines

> Well, if I change `rev.diffopt.use_color != GIT_COLOR_ALWAYS` to
> `rev.diffopt.use_color == GIT_COLOR_AUTO`, then the files will contain
> ugly ANSI color sequences if I run `git format-patch -o . -3`.
>
> The reason is, as I tried to explain, that the use_color field is *not*
> initialized to GIT_COLOR_AUTO (which is equivalent to 2), but to -1.

OK. I thought forcing no-color only when it is set to COLOR_AUTO or it is set to -1 (the default) would be safer, but I changed my mind.

"when we add a new --color=<something.we.do.not.know.yet>, overriding that end-user wish with the unconditional no-color is likely to be seen as bug." was the implicit bias behind that suggestion, but that is not substanticated and substatiatable.

If we write

	if (rev.diffopt.use_color != GIT_COLOR_ALWAYS)
        	rev.diffopt.use_color = 0;

and if a user of --color=<something.we.do.not.know.yet> wonders why her output is not colored, it is clear in the code above that we disable unless it is set with --color=always, so it won't make fixing such a future breakage harder. In fact, if we did

	if (rev.diffopt.use_color == GIT_COLOR_AUTO ||
            rev.diffopt.use_color < 0)
        	rev.diffopt.use_color = 0;

it would make it _harder_ to spot where use_color is turned off when the person who debugs such an issue.

Thanks.