author | Jeff King <peff@peff.net> | |
Thu, 9 Dec 2010 17:27:08 +0000 (12:27 -0500) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Fri, 10 Dec 2010 20:59:52 +0000 (12:59 -0800) | ||
commit | 148135fc24dce1e61cfd7fcedea4210095099e78 | |
tree | b3fa5923cb325d677aeb12db1406d606c6b24b8a | tree | snapshot |
parent | 1d282327d7354dd3a1caefa4af06562aa816710d | commit | diff |
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>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
color.c | diff | blob | history | |
color.h | diff | blob | history | |
wt-status.c | diff | blob | history |