Hi Taylor, 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 > newline. > > 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 instead? Ciao, Dscho > + printf "\\033[31m" >expect && > + git config --get --type=color foo.color >actual && > test_cmp expect actual > ' > > -- > 2.20.1 >
