Jeff King <peff@xxxxxxxx> writes: > On Tue, Jan 07, 2025 at 09:47:43AM +0100, Patrick Steinhardt wrote: > >> On Mon, Jan 06, 2025 at 09:39:04PM -0500, Jeff King wrote: >> > 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. ;-) >> 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.
