Re: [PATCH] builtin/config.c: don't print a newline with --color
- Date: Sat, 2 Mar 2019 21:25:28 +0100 (STD)
- From: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
- Subject: Re: [PATCH] builtin/config.c: don't print a newline with --color
On Fri, 1 Mar 2019, Taylor Blau wrote:
> Invocations of 'git config <name>' print a trailing newline after
> writing the value assigned to the given configuration variable.
> This has an unexpected interaction with 63e2a0f8e9 (builtin/config:
> introduce `color` type specifier, 2018-04-09), which causes a newline to
> be printed after a color's ANSI escape sequence.
> In this case, printing a terminating newline is not desirable. Callers
> may want to print out such a configuration variable in a sub-shell in
> order to color something else, in which case they certainly don't want a
> This bug has survived because there was never a test that would have
> caught it. The old test used 'test_decode_color', which checks that its
> input begins with a color, but stops parsing once it has parsed a single
> color successfully. In this case, it was ignoring the trailing '\n'.
Isn't the reason rather that our test compared the output to an expected
text *with a newline*? IOW:
> diff --git a/t/t1300-config.sh b/t/t1300-config.sh
> index 428177c390..ec1b3a852d 100755
> --- a/t/t1300-config.sh
> +++ b/t/t1300-config.sh
> @@ -907,9 +907,8 @@ test_expect_success 'get --expiry-date' '
> test_expect_success 'get --type=color' '
> rm .git/config &&
> git config foo.color "red" &&
> - git config --get --type=color foo.color >actual.raw &&
> - test_decode_color <actual.raw >actual &&
> - echo "<RED>" >expect &&
This should do the right thing if you write
printf "<RED>" >expect
> + printf "\\033[31m" >expect &&
> + git config --get --type=color foo.color >actual &&
> test_cmp expect actual