Re: [PATCH v2 2/4] sideband: introduce an "escape hatch" to allow control characters

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 18, 2025, 02:22 UTC
Message-ID: <xmqqy0n0y1ep.fsf@gitster.g>
In-Reply-To: <2615abd8c5d5c55486cf5885c47e09e52fad61b8.1765981422.git.gitgitgadget@gmail.com>

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 11 quoted lines

> 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.<url>.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.