From: Phillip Wood Date: Fri, 13 Nov 2020 12:03:59 GMT Subject: Re: [PATCH v2 04/11] add -i: use `reset_color` consistently Message-ID: <6405f7c9-b084-ed48-e33e-009f388933bf@gmail.com> In-Reply-To: Hi Dscho On 11/11/2020 12:28, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > 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 > --- > 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; >