From: Markus Heidelberg <markus.heidelberg@web.de>
Date: Fri, 09 Jan 2009 16:24:59 GMT
Subject: Re: [PATCH, resend] git-commit: colored status when color.ui is set
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:
> 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 :)

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