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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 16, 2026, 15:21 UTC
Message-ID: <xmqq3445bn33.fsf@gitster.g>
In-Reply-To: <CA+B51BEs7kuJ7s+K2vbZLSoaq3krGrqVncQAaTjSSNazFLY3tw@mail.gmail.com>

Ondrej Pohorelsky <opohorel@redhat.com> writes:

Show 5 quoted lines

> Hi, I just want to weight in from the downstream maintainer POV.
> We've been carrying the patches Johannes has created in Fedora, CentOS
> and RHEL for at least half a year now.
> The only change I did is to make the new behavior opt-in by default
> and give the RHEL customers a release note explaining it.

Thanks for your great input. FWIW, I do not think anybody around here is against "opt-in with a note" approach at all.

> I think the patches proposed are making sense, and they should be
> merged. Even having them as opt-in is better than not having them
> merged at all.

I do not think anybody disagrees with this sentiment. Back when the patches originally was discussed on the public list here, nobody was against adding it as an _optional_ feature to filter some byte sequences out of the end-user's data stream, and the review comments that led to the topic marked to be "expecting a reroll", if I recall correctly, were all about "why would we make this on by default?" Peff's message that reignited the topic this time around is also about the same.

We are still hearing from Dscho that he cannot think of a scenario where making this mandatory with opt-out would break existing legitimate setup people may have (I am paraphrasing [*]), but I think that is aiming in the wrong direction. It does not matter if you consider the approach your users take is "broken by design"; as long as it works for them in their (limited) settings, it is a valid arrangement to send arbitrary byte sequence over the sideband even it happens to include ANSI escapes and other "curiosities". We have in no position to unilaterally break them, telling them that we left a way open for them to disable. That is not how to deliver features.

I strongly suspect that the reason why you made "The only change---opt-in by default" is from the same reasoning as above. Do not break end-users' set-up. As long as it works for them, it is not "broken by design" to them, and it is irresponsible to break their set-up.

But an opt-in way to filter suspicious byte sequences is a good thing, as such a mechanism did not exist before.

So in short, yes, everybody around here agrees with you that the feature as an opt-in is a great addition.

[Footnote]

 * Here is from <c0af9072-cf21-a7e2-5b78-eb70217b462c@gmx.de>
   without my paraphrasing.

   """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?"""