{"thread":{"id":"63003","subject":"\\b character escapes in CLI usage","startedAt":"2025-02-25T23:44:37Z","lastAt":"2025-02-27T18:40:22Z","messageCount":15,"participants":["Yaakov Smith","Jeff King","Junio C Hamano","Kyle Lippincott","brian m. carlson","Marc Branchaud","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"513044","messageId":"SYBPR01MB579278DD5EC6E13CA9A213FDE2C32@SYBPR01MB5792.ausprd01.prod.outlook.com","threadId":"63003","inReplyTo":null,"subject":"\\b character escapes in CLI usage","fromName":"Yaakov Smith","fromEmail":"yaakov.smith@wisetechglobal.com","sentAt":"2025-02-25T23:44:33Z","receivedAt":"2025-02-25T23:44:37Z","isPatch":false,"sender":{"key":"yaakov.smith@wisetechglobal.com","avatar":null},"body":"Hi all,\n\nI'm not sure if this is a bug, but it definitely feels like a bug.\n\nA colleague of mine was going through the documentation for the git configuration file format and noticed that \\b is a permitted escape.\n\nIn some places, such as trying to fetch a remote with this in the URL, git will render the character differently.\n\n[remote \"backslashb\"]\n url = \"\\b\"\n fetch = +refs/heads/*:refs/remotes/backslashb/*\n\n$ git fetch backslashb\nfatal: '?' does not appear to be a git repository\nfatal: Could not read from remote repository.\n\nWhen 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:\n\n$ cat .git/config\n[core]\n somevalue = \"true\\b\\b\\b\\bfalse\"\n$ git config --local --list\ncore.somevalue=false\n\nShould \"git config\" be smarter here and print something other than a literal backspace to the terminal, like \"git fetch\" does?\n\n[System Info]\ngit version:\ngit version 2.34.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64\ncompiler info: gnuc: 11.4\nlibc info: glibc: 2.35\n$SHELL (typically, interactive shell): /bin/bash\n\nKind regards,\nYaakov Smith\nPrincipal Software Engineer\nPronouns: he/him \ne yaakov.smith@wisetechglobal.com\nt    +61 (2) 8001 2200\nd   +61 (2) 8986 2753\nwisetechglobal.com \n\nEnabling and empowering the world's supply chains. \nThis email is subject to our Confidentiality Statement \n\n"},{"id":"513052","messageId":"20250226073822.GA21138@coredump.intra.peff.net","threadId":"63003","inReplyTo":"SYBPR01MB579278DD5EC6E13CA9A213FDE2C32@SYBPR01MB5792.ausprd01.prod.outlook.com","subject":"Re: \\b character escapes in CLI usage","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-02-26T07:38:22Z","receivedAt":"2025-02-26T07:38:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 25, 2025 at 11:44:33PM +0000, Yaakov Smith wrote:\n\n> In some places, such as trying to fetch a remote with this in the URL, git will render the character differently.\n> \n> [remote \"backslashb\"]\n> url = \"\\b\"\n> fetch = +refs/heads/*:refs/remotes/backslashb/*\n> \n> $ git fetch backslashb\n> fatal: '?' does not appear to be a git repository\n> fatal: Could not read from remote repository.\n\nHere we sanitize error output, because we know the result is human\nreadable (and likely to be showing untrusted input from the repo or a\nremote server).\n\n> 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:\n> \n> $ cat .git/config\n> [core]\n> somevalue = \"true\\b\\b\\b\\bfalse\"\n> $ git config --local --list\n> core.somevalue=false\n\nBut here, the point of \"git config\" is to show the output. If we\nsanitized it (especially in a lossy way like we do for error messages),\nthen any program reading the output would not see the real data.\n\n> Should \"git config\" be smarter here and print something other than a\n> literal backspace to the terminal, like \"git fetch\" does?\n\nSo I would say no here, in general.\n\nWe could perhaps try to be kinder about sanitizing output when it is\ngoing to a terminal, rather than a pipe. But quite curiously, that\nshould already be the case for \"config --list\"! It invokes a pager by\ndefault. Much to my surprise, though, \"less\" does not seem to treat\nbackspace as a control character. It can be configured to do so:\n\n $ LESS=FRXU git config --list --local\n ...\n core.foo=true^H^H^H^Hfalse\n\nHere's what the manpage for less(1) says:\n\n By default, if neither -u nor -U is given, backspaces which appear\n adjacent to an underscore character are treated specially: the\n underlined text is displayed using the terminal's hardware underlining\n capability. Also, backspaces which appear between two identical\n characters are treated specially: the overstruck text is printed using\n the terminal's hardware boldface capability. Other backspaces are\n deleted, along with the preceding character.[...]\n\nSo I guess it is intentional to allow programs to use some effects, but\nin general I think I might prefer them being marked visually. Especially\nbecause the same would be true in a diff, like:\n\n git init\n echo old >file && git add file && git commit -m old\n printf 'sneaky\\b\\b\\b\\b\\bnew\\n' >file && git commit -m new\n git show\n\nwhich respects the backspaces (actually it says \"snew\" with a bolded \"n\"\nbecause of the overstrike rule ;) ).\n\nI wonder if we should consider adding \"U\" to the default $LESS variable\nwe set.\n\n-Peff\n"},{"id":"513055","messageId":"20250226080902.GA29996@coredump.intra.peff.net","threadId":"63003","inReplyTo":"20250226073822.GA21138@coredump.intra.peff.net","subject":"Re: \\b character escapes in CLI usage","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-02-26T08:09:02Z","receivedAt":"2025-02-26T08:09:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 26, 2025 at 02:38:23AM -0500, Jeff King wrote:\n\n> I wonder if we should consider adding \"U\" to the default $LESS variable\n> we set.\n\nHaving tried this for 5 minutes, the answer is a resounding \"no\". It\nalso treats tabs as control characters, making source code diffs rather\nugly. ;)\n\nIn modern versions of less you can get around it with:\n\n LESS=\"-U --proc-tab\"\n\nor:\n\n LESS=\"--PROC-BACKSPACE\"\n\nbut those are new in less 632, from the last year or two. So I don't\nthink we can rely on it in our default variable, but people with recent\nversions of less should consider setting it.\n\nLooks like it was added for exactly this case:\n\n https://github.com/gwsw/less/issues/335\n\n-Peff\n"},{"id":"513105","messageId":"xmqqcyf4g0hx.fsf@gitster.g","threadId":"63003","inReplyTo":"20250226073822.GA21138@coredump.intra.peff.net","subject":"Re: \\b character escapes in CLI usage","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-02-26T15:59:54Z","receivedAt":"2025-02-26T15:59:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I wonder if we should consider adding \"U\" to the default $LESS variable\n> we set.\n\nThanks for analyzing the \"less\" issue.\n\nWe should be OK if we lost the overstrike from the pager we directly\nspawn and write into. I think it is a good thing to consider,\nespecially because \"the default $LESS variable we set\" should not\naffect the pager indirectly triggered by us spawning \"man\".\n\nThanks.\n"},{"id":"513106","messageId":"xmqq8qpsg0e7.fsf@gitster.g","threadId":"63003","inReplyTo":"20250226080902.GA29996@coredump.intra.peff.net","subject":"Re: \\b character escapes in CLI usage","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-02-26T16:02:08Z","receivedAt":"2025-02-26T16:02:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Feb 26, 2025 at 02:38:23AM -0500, Jeff King wrote:\n>\n>> I wonder if we should consider adding \"U\" to the default $LESS variable\n>> we set.\n>\n> Having tried this for 5 minutes, the answer is a resounding \"no\". It\n> also treats tabs as control characters, making source code diffs rather\n> ugly. ;)\n\n;-)\n"},{"id":"513109","messageId":"CAO_smVjC=CWeAEjZjr9PPuBTkyYus59o_J9hfnpJCB-AsBE0HA@mail.gmail.com","threadId":"63003","inReplyTo":"20250226080902.GA29996@coredump.intra.peff.net","subject":"Re: \\b character escapes in CLI usage","fromName":"Kyle Lippincott","fromEmail":"spectral@google.com","sentAt":"2025-02-26T16:38:15Z","receivedAt":"2025-02-26T16:38:27Z","isPatch":false,"sender":{"key":"spectral@google.com","avatar":"https://avatars.githubusercontent.com/u/6371650?v=4"},"body":"On Wed, Feb 26, 2025 at 12:09 AM Jeff King wrote:\n>\n> On Wed, Feb 26, 2025 at 02:38:23AM -0500, Jeff King wrote:\n>\n> > I wonder if we should consider adding \"U\" to the default $LESS variable\n> > we set.\n>\n> Having tried this for 5 minutes, the answer is a resounding \"no\". It\n> also treats tabs as control characters, making source code diffs rather\n> ugly. ;)\n>\n> In modern versions of less you can get around it with:\n>\n> LESS=\"-U --proc-tab\"\n>\n> or:\n>\n> LESS=\"--PROC-BACKSPACE\"\n>\n> but those are new in less 632, from the last year or two. So I don't\n> think we can rely on it in our default variable, but people with recent\n> versions of less should consider setting it.\n\nFrom another issue (https://github.com/gwsw/less/issues/557) I learned\nyou can do this:\n\nLESSKEY_CONTENT='#env;#version>=632 LESS=${LESS} --PROC-BACKSPACE'\n\nI haven't tested it yet, but that might be a decent solution? I don't\nknow how composable those are; e.g. if you wanted both\n--PROC-BACKSPACE on >=632 and --no-poll on >=670, I'm *assuming* you\ncan do that, but I don't know what the syntax looks like.\n\n>\n> Looks like it was added for exactly this case:\n>\n> https://github.com/gwsw/less/issues/335\n>\n> -Peff\n>\n"},{"id":"513120","messageId":"20250226220628.GA600528@coredump.intra.peff.net","threadId":"63003","inReplyTo":"CAO_smVjC=CWeAEjZjr9PPuBTkyYus59o_J9hfnpJCB-AsBE0HA@mail.gmail.com","subject":"Re: \\b character escapes in CLI usage","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-02-26T22:06:28Z","receivedAt":"2025-02-26T22:06:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 26, 2025 at 08:38:15AM -0800, Kyle Lippincott wrote:\n\n> > In modern versions of less you can get around it with:\n> >\n> > LESS=\"-U --proc-tab\"\n> >\n> > or:\n> >\n> > LESS=\"--PROC-BACKSPACE\"\n> >\n> > but those are new in less 632, from the last year or two. So I don't\n> > think we can rely on it in our default variable, but people with recent\n> > versions of less should consider setting it.\n> \n> From another issue (https://github.com/gwsw/less/issues/557) I learned\n> you can do this:\n> \n> LESSKEY_CONTENT='#env;#version>=632 LESS=${LESS} --PROC-BACKSPACE'\n> \n> I haven't tested it yet, but that might be a decent solution? I don't\n> know how composable those are; e.g. if you wanted both\n> --PROC-BACKSPACE on >=632 and --no-poll on >=670, I'm *assuming* you\n> can do that, but I don't know what the syntax looks like.\n\nThanks for the pointer, I didn't know about that. I think it is fully\ncomposable, as the \"#version\" conditional just applies to one line. So:\n\n LESSKEY_CONTENT='#env;#version>=632 LESS=${LESS} --PROC-BACKSPACE;#version >=670 LESS=${LESS} --no-poll'\n\nHowever, I couldn't get even the basic version to work. Turns out that\nLESSKEY_CONTENT was added in 645, and I'm running 643 from Debian\nunstable).\n\nSo it kind-of works for our case if we make 645 the minimum (and don't\nhelp versions between 632 and 645 at all). I think we could get even\nhackier to support old versions like:\n\n # probably would be $prefix/share/git/lesskey in a real install\n fn=/tmp/lesskey\n {\n\techo \"#env\"\n\techo \"#version >= 632 LESS=${LESS} --PROC-BACKSPACE\"\n } >\"$fn\"\n\n # This works back to less 582. Before that we have to compile it to a\n # binary format with \"lesskey\" and point to it with $LESSKEY.\n LESSKEYIN=$fn git log\n\nI guess we'd also need to put more details into setup_pager_env(). Right\nnow its logic is just \"do not set $FOO if $FOO is already set\". But we'd\nprobably want rules like \"if $LESS is set, do not try to override it\nwith $LESSKEY_CONTENT\".\n\nI'm inclined to punt on it for a while. People can set up $LESS\nthemselves based on what they have available, and once these features\nhave been around for a while, we might then consider adding them to our\ndefaults.\n\n-Peff\n"},{"id":"513127","messageId":"Z7-lbGnlzGbhrHZN@tapette.crustytoothpaste.net","threadId":"63003","inReplyTo":"20250226073822.GA21138@coredump.intra.peff.net","subject":"Re: \\b character escapes in CLI usage","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-02-26T23:36:12Z","receivedAt":"2025-02-26T23:36:20Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-02-26 at 07:38:22, Jeff King wrote:\n> On Tue, Feb 25, 2025 at 11:44:33PM +0000, Yaakov Smith wrote:\n> > 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:\n> > \n> > $ cat .git/config\n> > [core]\n> > somevalue = \"true\\b\\b\\b\\bfalse\"\n> > $ git config --local --list\n> > core.somevalue=false\n> \n> But here, the point of \"git config\" is to show the output. If we\n> sanitized it (especially in a lossy way like we do for error messages),\n> then any program reading the output would not see the real data.\n\nYes, I should point out that, among other programs, Git LFS reads this\noutput. Changing the output format would break those programs.\n\n> > Should \"git config\" be smarter here and print something other than a\n> > literal backspace to the terminal, like \"git fetch\" does?\n> \n> So I would say no here, in general.\n\nI agree this is the right choice in general. I wonder if we might want\nsome sort of human-readable output option that might escape these that\nusers could use. The output might still be machine-readable, but it\nmight be easier to parse than the current format, which has some tricky\nedge cases when a config value contains newlines.\n\nWe already have precedent for this in core.quotePath and could easily\nuse similar logic here. That format, while using octal, which I find\nugly and hard to read, does have the pleasant side effect that it works\ncorrectly with POSIX printf(1) (which I'm sure was intentional), unlike\nhex escapes.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"513128","messageId":"xmqqtt8g9s82.fsf@gitster.g","threadId":"63003","inReplyTo":"Z7-lbGnlzGbhrHZN@tapette.crustytoothpaste.net","subject":"Re: \\b character escapes in CLI usage","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-02-26T23:55:09Z","receivedAt":"2025-02-26T23:55:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> We already have precedent for this in core.quotePath and could easily\n> use similar logic here. That format, while using octal, which I find\n> ugly and hard to read, does have the pleasant side effect that it works\n> correctly with POSIX printf(1) (which I'm sure was intentional), unlike\n> hex escapes.\n\nIt was intended to be \"the normal C quoting\":\n\nhttps://lore.kernel.org/git/87ek6s0w34.fsf@penguin.cs.ucla.edu/\n\n"},{"id":"513129","messageId":"xmqqplj49rul.fsf@gitster.g","threadId":"63003","inReplyTo":"Z7-lbGnlzGbhrHZN@tapette.crustytoothpaste.net","subject":"Re: \\b character escapes in CLI usage","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-02-27T00:03:14Z","receivedAt":"2025-02-27T00:03:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> I agree this is the right choice in general. I wonder if we might want\n> some sort of human-readable output option that might escape these that\n> users could use.\n> The output might still be machine-readable, ...\n\nI wonder if isatty(1) is a good way to say \"ah, we are not captured\nin 'foo=$(git blah)' and not feeding somebody in 'git blah |\nsomebody', so we do not have to worry about being machine readable\".\nIf that is a reliable way to tell that we could butcher our output\nfor the sake of keeping the terminal state sane, we then can always\ndo the C-quote escaping, or even information losing '?' redaction.\n\n"},{"id":"513147","messageId":"3a58720f-a572-4e3a-bed1-cc7e8f46e3c7@xiplink.com","threadId":"63003","inReplyTo":"xmqqplj49rul.fsf@gitster.g","subject":"General output formatting (was: Re: \\b character escapes in CLI usage)","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2025-02-27T14:06:52Z","receivedAt":"2025-02-27T14:06:56Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"\nOn 2025-02-26 19:03, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n>> I agree this is the right choice in general. I wonder if we might want\n>> some sort of human-readable output option that might escape these that\n>> users could use.\n>> The output might still be machine-readable, ...\n> \n> I wonder if isatty(1) is a good way to say \"ah, we are not captured\n> in 'foo=$(git blah)' and not feeding somebody in 'git blah |\n> somebody', so we do not have to worry about being machine readable\".\n> If that is a reliable way to tell that we could butcher our output\n> for the sake of keeping the terminal state sane, we then can always\n> do the C-quote escaping, or even information losing '?' redaction.\n\nModern practice seems to be moving towards explicit format options to \nlet code that's parsing output directly specify how it wants to see the \ndata. Such options eliminate the need for isatty() heuristics and other \nguesswork.\n\nFor example, the ip command (at least in Ubuntu) accepts -j to format \noutput as JSON. I've found this to be immensely helpful for my scripts.\n\nI'm sure Git scripters would appreciate something similar, perhaps as a \nglobal \"--format=X\" option to \"git\" itself. isatty() heuristics could \nstill be used when no formatting option is specified (though I suspect \nin the long run the default will end up being terminal-friendly output).\n\nThis would certainly be a large effort, but once the basic pattern is \nworked out it could be incrementally implemented one command at a time.\n\n\t\tM.\n\n"},{"id":"513165","messageId":"f455db00-2064-4c2f-be2e-6c5970843f03@gmail.com","threadId":"63003","inReplyTo":"Z7-lbGnlzGbhrHZN@tapette.crustytoothpaste.net","subject":"Re: \\b character escapes in CLI usage","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-02-27T16:26:44Z","receivedAt":"2025-02-27T16:26:47Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 26/02/2025 23:36, brian m. carlson wrote:\n> On 2025-02-26 at 07:38:22, Jeff King wrote:\n>> On Tue, Feb 25, 2025 at 11:44:33PM +0000, Yaakov Smith wrote:\n>>> \n>>> Should \"git config\" be smarter here and print something other than a\n>>> literal backspace to the terminal, like \"git fetch\" does?\n>>\n>> So I would say no here, in general.\n> \n> I agree this is the right choice in general. I wonder if we might want\n> some sort of human-readable output option that might escape these that\n> users could use. The output might still be machine-readable, but it\n> might be easier to parse than the current format, which has some tricky\n> edge cases when a config value contains newlines.\n\nWe have '-z' to avoid that ambiguity. I agree that having an option to \nprovide a human-readable output would be a nice addition.\n\nBest Wishes\n\nPhillip\n\n> We already have precedent for this in core.quotePath and could easily\n> use similar logic here. That format, while using octal, which I find\n> ugly and hard to read, does have the pleasant side effect that it works\n> correctly with POSIX printf(1) (which I'm sure was intentional), unlike\n> hex escapes.\n\n"},{"id":"513168","messageId":"xmqq34fz9v1n.fsf@gitster.g","threadId":"63003","inReplyTo":"3a58720f-a572-4e3a-bed1-cc7e8f46e3c7@xiplink.com","subject":"Re: General output formatting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-02-27T17:06:28Z","receivedAt":"2025-02-27T17:06:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n>> I wonder if isatty(1) is a good way to say \"ah, we are not captured\n>> in 'foo=$(git blah)' and not feeding somebody in 'git blah |\n>> somebody', so we do not have to worry about being machine readable\".\n>> If that is a reliable way to tell that we could butcher our output\n>> for the sake of keeping the terminal state sane, we then can always\n>> do the C-quote escaping, or even information losing '?' redaction.\n>\n> Modern practice seems to be moving towards explicit format options to\n> let code that's parsing output directly specify how it wants to see\n> the data. Such options eliminate the need for isatty() heuristics and\n> other guesswork.\n\nI am not opposed to an explicit \"please avoid raw binary output\" or\neven \"please make it even more machine-processable by formatting in\nyaml\" options. What I was hinting at was what the default should be\nfor interactive use when the output goes directly to the eyes of\nend-users, which is pretty much orthogonal.\n\nThanks.\n"},{"id":"513169","messageId":"18ed50b3-e5a4-43b3-a543-f9a3d2c309e6@xiplink.com","threadId":"63003","inReplyTo":"xmqq34fz9v1n.fsf@gitster.g","subject":"Re: General output formatting","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2025-02-27T17:14:42Z","receivedAt":"2025-02-27T17:14:45Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"\nOn 2025-02-27 12:06, Junio C Hamano wrote:\n> Marc Branchaud writes:\n> \n>>> I wonder if isatty(1) is a good way to say \"ah, we are not captured\n>>> in 'foo=$(git blah)' and not feeding somebody in 'git blah |\n>>> somebody', so we do not have to worry about being machine readable\".\n>>> If that is a reliable way to tell that we could butcher our output\n>>> for the sake of keeping the terminal state sane, we then can always\n>>> do the C-quote escaping, or even information losing '?' redaction.\n>>\n>> Modern practice seems to be moving towards explicit format options to\n>> let code that's parsing output directly specify how it wants to see\n>> the data. Such options eliminate the need for isatty() heuristics and\n>> other guesswork.\n> \n> I am not opposed to an explicit \"please avoid raw binary output\" or\n> even \"please make it even more machine-processable by formatting in\n> yaml\" options. What I was hinting at was what the default should be\n> for interactive use when the output goes directly to the eyes of\n> end-users, which is pretty much orthogonal.\n\nSorry, I read \"if that is a reliable way to tell\" as looking for \nreliability.\n\nI have no opinion on exactly how to \"butcher\" the output for a terminal. \n I guess it depends on how well Git wants to support copy/paste of its \noutput.\n\n\t\tM.\n\n"},{"id":"513179","messageId":"xmqqfrjz6xkc.fsf@gitster.g","threadId":"63003","inReplyTo":"18ed50b3-e5a4-43b3-a543-f9a3d2c309e6@xiplink.com","subject":"Re: General output formatting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-02-27T18:40:19Z","receivedAt":"2025-02-27T18:40:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> I have no opinion on exactly how to \"butcher\" the output for a\n> terminal. I guess it depends on how well Git wants to support\n> copy/paste of its output.\n\nYup, that is a fine balancing act. Given the current behaviour,\n\n $ cat .git/config\n [core]\n somevalue = \"true\\b\\b\\b\\bfalse\"\n $ git config --local --list\n core.somevalue=false\n\nsupporting copy-paste may not be such a good thing to do, though ;-)\n"}]}