On 2025-02-26 at 07:38:22, Jeff King wrote: > On Tue, Feb 25, 2025 at 11:44:33PM +0000, Yaakov Smith wrote: > > When using "git config --list" however, this is emitted in its raw format, and can be used to mask or hide an actual (probably invalid) value: > > > > $ cat .git/config > > [core] > > somevalue = "true\b\b\b\bfalse" > > $ git config --local --list > > core.somevalue=false > > But here, the point of "git config" is to show the output. If we > sanitized it (especially in a lossy way like we do for error messages), > then any program reading the output would not see the real data. Yes, I should point out that, among other programs, Git LFS reads this output. Changing the output format would break those programs. > > Should "git config" be smarter here and print something other than a > > literal backspace to the terminal, like "git fetch" does? > > So I would say no here, in general. I agree this is the right choice in general. I wonder if we might want some sort of human-readable output option that might escape these that users could use. The output might still be machine-readable, but it might be easier to parse than the current format, which has some tricky edge cases when a config value contains newlines. We already have precedent for this in core.quotePath and could easily use similar logic here. That format, while using octal, which I find ugly and hard to read, does have the pleasant side effect that it works correctly with POSIX printf(1) (which I'm sure was intentional), unlike hex escapes. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
