Jeff King <p...@peff.net> writes:
>> +static int clean_use_color = -1;
>> +static char clean_colors[][COLOR_MAXLEN] = {
>> + [CLEAN_COLOR_RESET] = GIT_COLOR_RESET,
>> + [CLEAN_COLOR_PLAIN] = GIT_COLOR_NORMAL,
>> + [CLEAN_COLOR_PROMPT] = GIT_COLOR_BOLD_BLUE,
>> + [CLEAN_COLOR_HEADER] = GIT_COLOR_BOLD,
>> + [CLEAN_COLOR_HELP] = GIT_COLOR_BOLD_RED,
>> + [CLEAN_COLOR_ERROR] = GIT_COLOR_BOLD_RED,
>> +};
>
> I think this is much nicer to read. I assume if we have a "hole" in our
> numbering that the hole is initialized in the usual static way (a
> COLOR_MAXLEN array full of NULs in this case, I guess)?
I would expect that would be the case.
Do we need to have a check to detect a buggy compiler that takes the
syntax but produces an incorrectly initialized array? I could add a
test to ensure that HEADER comes out BOLD, etc. (or we may already
have such a test) and then reorder these lines in this patch, if
that is the kind of breakage we anticipate.
