Thread (1 message) 1 message, 1 author, 2025-01-09

Re: [PATCH 02/10] t7422: fix flaky test caused by buffered stdout

From: Junio C Hamano <hidden>
Date: 2025-01-09 16:16:44

Jeff King [off-list ref] writes:
On Tue, Jan 07, 2025 at 09:47:43AM +0100, Patrick Steinhardt wrote:
quoted
On Mon, Jan 06, 2025 at 09:39:04PM -0500, Jeff King wrote:
quoted
So I don't really see a way to do this robustly.
I think I found a way, which goes back to the inital idea of just
generating heaps of submodules.
...
Your solution looks nice. It's O(1) processes, since all of the heavy
lifting is done by the long gitmodules file and tree.

I was going to suggest that you could reduce the number of submodules by
giving them large paths (or large checked-out branch names) to get more
bytes of output per submodule. But there is not really much point. What
you have should run quite quickly.
;-)
quoted
I'm a bit torn though. The required setup is quite complex, and I wonder
whether it is really worth it just to test this edge case. On the other
hand it is there to cover a recent fix in 082caf527e (submodule status:
propagate SIGPIPE, 2024-09-20), so losing the test coverage isn't all
that great, either. And keeping the race is not an option to me, either.

So I'm inclined to go with the below version. WDYT?
Yeah, I was tempted after my last email to suggest just ditching the
test, too. :) But I think what you've written here is a good approach.
I'll look carefully over what you sent in the v3 series.
Yeah.  Thanks, both.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help