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

On Tue, Jan 20, 2026 at 09:05:27AM -0800, Junio C Hamano wrote:

"brian m. carlson" [off-list ref] writes:

quoted

I'm not opposed to adding support for this as an opt-in feature for
those people that want it, though, and I think that's the right path for
including it.

Yup.  I am hoping that there are no folks who think that forcing
this filtering on everybody is so important that it must not go in
unless it is enabled by default.

If we cannot agree then I'd rather take the opt-in compared to having
nothing at all.

I however wonder if we need two different levels defaults, depending
on where the user is going, to make it less painful to configure
things.  I would imagine the remotes one would interact with fall
into two quite different categories.

 - The ones that you talk with every day, essential in your work,
   would be something you would have to be able to trust and if
   these trusted people want to give you a bit more colorful output
   from their hooks, you shouldn't have to manually configure "I
   accept colors from them", for example.

 - There are others that you will visit for the first time as you
   try to discover new good things.  These you may want to be extra
   cautious about than the familiar remotes in your everyday work.

Perhaps "git clone $URL" should filter the terminal output by
default, but once inside the resulting repository, "git push" and
"git pull" from the established remote that is used by default when
you do not say whom to talk to, our default can be more lenient, or
something?

I'm not sure this would help protect our users. If we had an adversarial
remote, then it could trivially work around the protection by acting
benevolent on clone, but malicious on subsequent fetches. So it doesn't
really seem to significantly reduce the attack surface, unless I miss
something.

I think that the other suggestion you made further up the thread would
make more sense in this context. If users can configure this similar to
how our "http.<url>.*" settings work then they can e.g.:

    $ git config set --global \
        sideband."https://gitlab.com".allowControlCharacters true

And from thereon they would always trust GitLab going forward. I guess
that most users would really only need to configure two or three such
domains.

NB: This ignores the fact that GitLab.com already behaves well with the
    proposed new default as we never send ANSI escape sequences other
    than color codes. So I assume most domains wouldn't need any
    configuration in the first place.

Thanks!

Patrick