From 148135fc24dce1e61cfd7fcedea4210095099e78 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Thu, 9 Dec 2010 12:27:08 -0500 Subject: 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 Signed-off-by: Junio C Hamano --- color.h | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'color.h') diff --git a/color.h b/color.h index 03ca064748..170ff4074d 100644 --- a/color.h +++ b/color.h @@ -43,6 +43,9 @@ #define GIT_COLOR_BG_MAGENTA "\033[45m" #define GIT_COLOR_BG_CYAN "\033[46m" +/* A special value meaning "no color selected" */ +#define GIT_COLOR_NIL "NIL" + /* * This variable stores the value of color.ui */ @@ -62,4 +65,6 @@ int color_fprintf(FILE *fp, const char *color, const char *fmt, ...); __attribute__((format (printf, 3, 4))) int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...); +int color_is_nil(const char *color); + #endif /* COLOR_H */ -- cgit v1.2.3