[PATCH] parse_color: fix return value for numeric color values 0-8

[Jeff King <peff@peff.net>]

On Tue, Jan 20, 2015 at 10:49:32PM +0100, Ævar Arnfjörð Bjarmason wrote:

> I've had this in my .gitconfig since 2010 which was broken by Jeff's
> v2.1.3-24-g695d95d:
> 
>     ;; Don't be so invasive about coloring ^M when I'm editing files
> that
>     ;; are supposed to have \r\n.
>     [color "diff"]
>        whitespace = 0
>
> [...]
> Maybe breaking this is OK (but I can't find what the replacement is),
> but the config or the the changelog doesn't mention breaking existing
> config settings.

Eek. Definitely an unintended regression. The fix is below. Thanks for
reporting (and especially for catching during the -rc period!).

You should not need it, but for reference, using "0" is the same as
"black" (both in old git and new).

-- >8 --
When commit 695d95d refactored the color parsing, it missed
a "return 0" when parsing literal numbers 0-8 (which
represent basic ANSI colors), leading us to report these
colors as an error.

Signed-off-by: Jeff King <peff@peff.net>
---
 color.c          | 1 +
 t/t4026-color.sh | 4 ++++
 2 files changed, 5 insertions(+)

diff --git a/color.c b/color.c
index 809b359..9027352 100644
--- a/color.c
+++ b/color.c
@@ -112,6 +112,7 @@ static int parse_color(struct color *out, const char *name, int len)
 		} else if (val < 8) {
 			out->type = COLOR_ANSI;
 			out->value = val;
+			return 0;
 		} else if (val < 256) {
 			out->type = COLOR_256;
 			out->value = val;
diff --git a/t/t4026-color.sh b/t/t4026-color.sh
index 267c43b..4d20fea 100755
--- a/t/t4026-color.sh
+++ b/t/t4026-color.sh
@@ -60,6 +60,10 @@ test_expect_success 'absurdly long color specification' '
 	  "[1;2;4;5;7;22;24;25;27;38;2;255;255;255;48;2;255;255;255m"
 '
 
+test_expect_success '0-7 are aliases for basic ANSI color names' '
+	color "0 7" "[30;47m"
+'
+
 test_expect_success '256 colors' '
 	color "254 bold 255" "[1;38;5;254;48;5;255m"
 '
-- 
2.2.1.425.g441bb3c