From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 10 Dec 2010 19:55:56 GMT
Subject: Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)
Message-ID: <7vk4jhcshf.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20101209172708.GA1817@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> Subject: [PATCH] default color.status.branch to "same as header"
>
> This gives it the same behavior as we had prior to 1d28232
> (status: show branchname with a configurable color).
>
> To do this we need the concept of a "NIL" color, which is
> provided by color.[ch]. The implementation is very simple;
> in particular, there are no precautions taken against code
> accidentally printing the NIL. This should be fine in
> practice because:
>
>   1. You can't input a NIL color in the config, so it must
>      come from the in-code defaults. Which means it is up
>      the client code to handle the NILs it defines.
>
>   2. If we do ever print a NIL, it will be obvious what the
>      problem is, and the bug can be fixed.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I resisted the urge to make a generic "same as $X" token, which would
> allow users to do something like:
>
>   [color "status"]
>     branch = from:color.status.header
>
> if they really wanted. But that would be a lot more code, and I'm not
> sure it would be all that useful (it would be if people did stuff like
> theming git colors like they do window managers, but I don't think we
> are at quite that level).

Also if you go that route you would need to worry about dependencies,
which would not be worth it.

> This is simple, solves the current regression, and provides an easy
> blueprint for handling the case in the future.

As I said, I don't care deeply, but you obviously cared enough to produce
a patch that is pretty simple and straightforward.  Let's take it.

Thanks.