Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)

Jeff King [off-list ref] 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 <redacted>
---
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.