Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

> Hi Junio, Jeff, and other interested parties,
> 
> On Thu, 15 Jan 2026, Junio C Hamano wrote:
> 
> > Jeff King <peff@peff.net> writes:
> > 
> > > Is there any reason we cannot introduce the new functionality as a
> > > config option but _not_ enable it by default?
> > >
> > > That gives people the tools to protect themselves if they want to bear
> > > the potential cost. It just feels a shame to deny them the tool because
> > > we can't agree on the default.
> > 
> > Yeah, I like the suggestion---making it opt-in would have much less
> > chance of breaking set-up people are relying on all of a sudden.
> 
> Can you help me understand how these existing use cases (which are not
> actually in wide-spread use) aren't broken by design, given that they have
> no chance to ensure that their ANSI sequences go to an actual terminal
> that can understand those sequences?
> 
> As such, it looks to me as if they have a valid goal, but go about it in a
> way that is easily improved: If they want color in their sideband output,
> then Git has to be taught about it, much in the same way as bf1a11f0a10
> (sideband: highlight keywords in remote sideband output, 2018-08-07)
> taught Git to highlight keywords in the remote sideband output. That is
> the actual correct way to do this, not by expecting Git to pass through
> all bytes to the terminal without sanitizing, which is a well-known worst
> practice (not even GNU tar does that when listing the contents of an
> archive, nor does cURL do that, just to list two of the command-line
> programs that sanitize properly what they pass on to the terminal).
> 
> Given that those use cases are rare (none of the popular Git forges
> support this!), and that it is a security issue, I still think that the
> default should be as I proposed: To pass through only a small subset of
> ANSI control sequences that you gentle people already agreed should be
> safe.