Re: [PATCH v2 5/5] builtin/config: do not spawn pager when printing color codes

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 15, 2025, 17:28 UTC
Message-ID: <xmqqikhjhbgo.fsf@gitster.g>
In-Reply-To: <20250915-pks-config-color-v2-5-e4290bd8d13c@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 12 quoted lines

> With `git config get --type=color` the user asks us to parse a specific
> configuration key and turn the value into an ANSI color escape sequence.
> The printed string can then for example be used as part of shell scripts
> to reuse the same colors as Git.
>
> Right now though we set up the auto-pager, which means that the string
> may instead be written to the pager command. This is of course quite
> nonsensical; there shouldn't be any use case where the color code should
> end up in the pager instead of in the TTY.
>
> Fix this by disabling the pager in case the user is asking us to print
> color sequences.

I am of two minds. Part of me obviously agrees that it is more straight forward with this change. But it may

An interactive user experimenting while writing their own script might say something like

 $ git config --type=color --default="reverse red" n.n

If the command emitted directly to the terminal, then everything they type from then on will be bloody red, but the pager protects them from such an accident. Instead, they are forced to say

 $ C=$(git config get --type=color --default="reverse red" n.n)
 $ R=$(git config get --type=color --default="reset" n.n)
 $ echo "So$C Bloody ${R}Red"

but these are likely what they would be writing in their script anyway, so...