(Sorry for replying only to Zach instead of everyone previously.) On Wed, Dec 13, 2023 at 4:20 PM Zach FettersMoore <zach.fetters@xxxxxxxxxxxxxxxxx> wrote: > > Christian Couder <christian.couder@xxxxxxxxx> writes: > > >>> > $ git subtree split --prefix=apollo-ios-codegen --squash --rejoin > >>> > Merge made by the 'ort' strategy. > >>> > e274aed3ba6d0659fb4cc014587cf31c1e8df7f4 > >>> > >>> Looking into this some it looks like it could be a bash config > >>> difference? My machine always runs it all the way through vs > >>> failing for recursion depth. Although that would also be an issue > >>> which is solved by this fix. > >> > >> I use Ubuntu where /bin/sh is dash so my current guess is that dash > >> might have a smaller recursion limit than bash. > > > > That sounds quite bad. Does it have to be recursive (iow, if we can > > rewrite the logic to be iterative instead, that would be a much better > > way to fix the issue)? > > I don't think an iterative vs recursive approach fixes this > particular issue, the root of the issue this patch is fixing > is that lots of commits from the history of subtrees not > being acted upon are being processed when they don't need to > be. So the iterative approach would likely resolve the > recursion limit issue for some shells, but in my instance > I don't see a recursion limit error, it just takes an > extraordinary amount of time to run the split command > because of all the unnecessary processing which needs to be > avoided which this patch fixes. Fixing possible recursion might be an improvement on top of your patch. But without your patch the test case it describes would anyway take a lot more time than seems necessary. So I agree that your patch should definitely be merged anyway.
