Re: [PATCH, resend] git-commit: colored status when color.ui is set

From: Markus Heidelberg <markus.heidelberg@web.de>
Date: Jan 9, 2009, 16:24 UTC
Message-ID: <200901091724.59983.markus.heidelberg@web.de>
In-Reply-To: <alpine.DEB.1.00.0901091155210.30769@pacific.mpi-cbg.de>

Johannes Schindelin, 09.01.2009:

Show 13 quoted lines

> Hi,
> 
> On Fri, 9 Jan 2009, Junio C Hamano wrote:
> 
> > Markus Heidelberg <markus.heidelberg@web.de> writes:
> > > When using "git commit" and there was nothing to commit (the editor
> > > wasn't launched), the status output wasn't colored, even though color.ui
> > > was set. Only when setting color.status it worked.
> > 
> > My first reaction was:
> > 
> > 	When the editor does get launched, what would the new code do with
> > 	your patch?  Would we see bunch of escape codes in the editor now?

Of course I tested this case :)

Show 7 quoted lines

> > But we do disable color explicitly when we generate contents to feed the
> > editor in that case since bc5d248 (builtin-commit: do not color status
> > output shown in the message template, 2007-11-18), so that fear is
> > unfounded.
> 
> I had the same reaction, so I would like to see this reasoning in the 
> commit message.

wt_status_use_color could have already been set during git_config() without this patch, just not with color.ui, but color.status, so this is not really a new case. But I can understand the reaction and don't have ocjections against this explanation in the commit message.

Markus