Hi Dscho On 11/11/2020 12:28, Johannes Schindelin via GitGitGadget wrote:
From: Johannes Schindelin <johannes.schindelin@xxxxxx> 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@xxxxxx> --- 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;
