Re: [PATCH v2 04/11] add -i: use `reset_color` consistently

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Dscho

On 11/11/2020 12:28, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> We already maintain a list of colors in the `add_i_state`, therefore we
> should use them.

Playing devil's advocate for a moment - why do we have a reset entry in 
that list? The next patch makes sure it cannot be customized which is a 
good thing so why not drop the `reset` member from `add_i_state` 
entirely? The perl version needed to get the reset string from `git 
config` and store it somewhere but in the C version we have a perfectly 
good constant we can use instead.

Best Wishes

Phillip


> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>   add-patch.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/add-patch.c b/add-patch.c
> index b6d53229bb..bf89c43145 100644
> --- a/add-patch.c
> +++ b/add-patch.c
> @@ -672,7 +672,7 @@ static void render_hunk(struct add_p_state *s, struct hunk *hunk,
>   		if (len)
>   			strbuf_add(out, p, len);
>   		else if (colored)
> -			strbuf_addf(out, "%s\n", GIT_COLOR_RESET);
> +			strbuf_addf(out, "%s\n", s->s.reset_color);
>   		else
>   			strbuf_addch(out, '\n');
>   	}
> @@ -1065,7 +1065,7 @@ static void recolor_hunk(struct add_p_state *s, struct hunk *hunk)
>   			      s->s.file_new_color :
>   			      s->s.context_color);
>   		strbuf_add(&s->colored, plain + current, eol - current);
> -		strbuf_addstr(&s->colored, GIT_COLOR_RESET);
> +		strbuf_addstr(&s->colored, s->s.reset_color);
>   		if (next > eol)
>   			strbuf_add(&s->colored, plain + eol, next - eol);
>   		current = next;
>