From: Junio C Hamano Date: Thu, 18 Dec 2025 02:22:22 GMT Subject: Re: [PATCH v2 2/4] sideband: introduce an "escape hatch" to allow control characters Message-ID: In-Reply-To: <2615abd8c5d5c55486cf5885c47e09e52fad61b8.1765981422.git.gitgitgadget@gmail.com> "Johannes Schindelin via GitGitGadget" writes: > diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt > new file mode 100644 > index 0000000000..3fb5045cd7 > --- /dev/null > +++ b/Documentation/config/sideband.txt > @@ -0,0 +1,5 @@ > +sideband.allowControlCharacters:: > + By default, control characters that are delivered via the sideband > + are masked, to prevent potentially unwanted ANSI escape sequences > + from being sent to the terminal. Use this config setting to override > + this behavior. Two thoughts. - Users may want to say "I trust this remote host" or "I trust this remote repository". For that, something similar to what we do to `http.variable` to allow `http..variable` to take precedence over `http.variable` would be necessary. - It may no longer matter but a remote repository that may send messages as strings encoded in ISO/IEC 2022 would need to set this, merely to make the messages human-readable. There may be other reasons the trusted repositories want to send "escape sequences". It might even be a good idea to make the default setting of this variable "allow", except for the initial connections to repositories (i.e., "git clone $URL", and "git fetch/ls-remote $URL" with an explicit $URL without using a nickname recorded in our .git/config), as visiting a potentially malicious remote repository you are not familiar with may not be uncommon, and users may deserve protection over inconvenience. But once the user establishes a working relationship with a remote repository, would it be a lot more common to trust the contents there than be on the lookout that the repository may spew bad strings of bytes at your standard error stream, I have to wonder.