Re: [PATCH 06/12] t: prepare execution of potentially failing commands for `set -e`

[Patrick Steinhardt <ps@pks.im>]

On Thu, Apr 16, 2026 at 01:49:24AM -0400, Jeff King wrote:
> On Wed, Apr 15, 2026 at 08:48:15AM +0200, Patrick Steinhardt wrote:
> 
> > > Personally, I am still skeptical that all of this is worth it versus
> > > just checking stderr.
> > 
> > Yeah, the more I dive into this topic the more sceptical I get, as well,
> > as shells behave wildly different around `set -e`. So I'm starting to
> > feel somewhat uncomfortable with the idea of blanket-enabling it for all
> > shells, as that will for sure lead to lots of fallout on platforms that
> > we're not testing.
> > 
> > Maybe we should really only do this for an allow-listed set of shells.
> > Starting with Bash 5 and newer might be good enough, and given that we
> > use Bash for some of our CI jobs we can assume that this would weed out
> > failures anyway.
> 
> Yeah, an allow-list is probably much better than trying to come up with
> a list of buggy shells. But that only helps with portability.
> 
> I'm still concerned that this approach is going to create extra friction
> for test writers down the road. This series needed to clean up several
> spots to avoid false positives, and some of the spots were non-trivial.
> 
> Now that was the accumulated cruft of 20 years of test-writing, so it's
> not clear to me how often new test-writers will run into this. But when
> they do, I worry that it may be hard to even figure out what is going
> on.
> 
> But I've said as much in earlier rounds, and I'm not sure Junio agrees.
> So we can note my dissent in the captain's log, and I can reserve the
> right to told-you-so later if need be. ;)

I don't necessarily disagree with your take, I do think this has the
potential to cause some pain. I guess the question is _how_ painful it
will get, and whether that additional pain is worth it to help us avoid
silent breakage like we recently had.

So I'd take a "merge and see" approach here, and if we ever notice that
it's too annoying we simply revert the last commit that introduced `set
-e`. It doesn't have to be a one-way decision.

Patrick