On Sun, Aug 03, 2025 at 03:30:32PM -0700, Junio C Hamano wrote:
> SZEDER Gábor <szeder.dev@xxxxxxxxx> writes:
>
> >> #!/bin/sh
> >> -WS=$(git config --get-color color.diff.whitespace "blue reverse")
> >> -RESET=$(git config --get-color "" "reset")
> >> +WS=$(git config get --type=color --default="blue reverse" color.diff.whitespace)
> >> +RESET=$(git config get --type=color --default="reset" "")
> >> echo "${WS}your whitespace color or blue reverse${RESET}"
> >
> > In this example the second command in the postimage doesn't work:
> >
> > $ RESET=$(git config get --type=color --default="reset" "")
> > error: key does not contain a section:
> >
> > Consequently, the last command doesn't work as expected anymore,
> > because the color is not reset at the end of the output.
> >
> > Luckily, the commands in the preimage still work.
>
> Instead of an empty string as a configuration variable, using
> something like no.such.variable that does not exist would also be
> a workaround. I.e.,
>
> RESET=$(git config get --type=color --default=reset no.such.variable)
>
> What is bad about this is that there is no generic variable that is
> guaranteed to be unset.
In fact that's even what our tests in t4026 do:
color()
{
actual=$(git config --get-color no.such.slot "$1") &&
test "$actual" = "${2:+$ESC}$2"
}
But that's certainly not great.
I'd say that the current behaviour is just a plain bug. In fact, there's
even two bugs:
1. We set up the pager when asked to print color codes. This does not
make any sense whatsoever, as these should never go to the pager
but should always be printed to stdout directly.
2. We don't recognize the special case where we have are asked for a
color, have an empty key but a default value.
I'll send a patch series to fix these.
Patrick
