mirrors/git
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

default color.status.branch to "same as header"

Browse Source 
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>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Jeff King
2010-12-09 12:27:08 -05:00
committed by Junio C Hamano
parent 1d282327d7
commit 148135fc24
3 changed files with 15 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
wt-status.c
View File

@ -21,12 +21,15 @@ static char default_wt_status_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RED, /* WT_STATUS_UNMERGED */
GIT_COLOR_GREEN, /* WT_STATUS_LOCAL_BRANCH */
GIT_COLOR_RED, /* WT_STATUS_REMOTE_BRANCH */
GIT_COLOR_NORMAL, /* WT_STATUS_ONBRANCH */
GIT_COLOR_NIL, /* WT_STATUS_ONBRANCH */
};
static const char *color(int slot, struct wt_status *s)
{
return s->use_color > 0 ? s->color_palette[slot] : "";
const char *c = s->use_color > 0 ? s->color_palette[slot] : "";
if (slot == WT_STATUS_ONBRANCH && color_is_nil(c))
c = s->color_palette[WT_STATUS_HEADER];
return c;
}
void wt_status_prepare(struct wt_status *s)