Jeff King <peff@xxxxxxxx> 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@xxxxxxxx> > --- > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html