On Tue, Jan 07, 2025 at 09:47:44AM +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. My current version generates a submodule > "A" with a couple of recursive submodules followed by 2.5k additional > submodules, which overall generates ~150kB of data. This can be done > somewhat efficiently via git-hash-object-object(1) and git-mktree(1), > and things work with a sleep before and after the call to grep(1). > > 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? Gah, this of course needs to be adapted so that it is the submodule that contains 2.5k recursive submodules. But the idea would still work. Patrick
