Re: [PATCH v6] subtree: fix split processing with multiple subtrees present

From: Zach FettersMoore <zach.fetters@apollographql.com>
Date: Dec 13, 2023, 15:20 UTC
Message-ID: <CAEWN6q2XeDDLvSM-ik_-HVqpeyYZLWpPwoj2SUyB9L9NyMJPLw@mail.gmail.com>
In-Reply-To: <xmqqzfyfoy2w.fsf@gitster.g>

Christian Couder <christian.couder@gmail.com> writes:

Show 15 quoted lines

>>> > $ 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.