From: Junio C Hamano Date: Fri, 13 Mar 2026 23:06:09 GMT Subject: Re: [PATCH v2 0/3] contrib/subtree: reduce recursion during split Message-ID: In-Reply-To: Junio C Hamano writes: > Colin Stagner writes: > >> * cs/subtree-split-recursion: when processing large history >> graphs on Debian or Ubuntu, "git subtree" can die with a >> "recursion depth reached" error. Reduce recursion. >> >> On Debian's POSIX sh, shell recursion is artificially limited >> to 1000 calls. You can check if your sh has limited recursion >> with: >> >> #!/bin/sh >> recurse() { >> r=$(( r + 1 )) >> test "$r" -le 1000 || { echo OK; exit; } >> recurse >> } && r=0 && recurse >> >> Depending on the history graph, subtree split can recurse deeply >> enough to encounter this limit. Rewrite the rejoin-deepening >> algorithm to reduce recursive calls. >> >> --- >> Changes in v2: >> - Rebase on master > > We have seen two iterations of this series without anybody > commenting on it. Is it a sign that the topic, or possibly "git > subtree" itself, is of interest to nobody? Or is it that it is so > well done that nobody had any comment on it? > > I don't use "git subtree" myself, and I do not know of anybody who > will scream at me if I break it by merging an unreviewed patch, so I > can merge it without worrying too much about fallout personally, but > that is a tad irresponsible as the maintainer ;-) > > So...? Any volunteers among those who have a higher stake in the > program than I do (which admittedly is not a high bar to cross)? FWIW, I can see that [1/3] is a benign clean-up that should not change any semantics. [2/3] talks about the variable $sub, which is used elsewhere, is not protected from getting overwritten by running the function inside a subprocess, but I do not know if updates to other variables (like $b, $sq, $repository, but not $fail_msg, $hint1 and $hint2 that are used only in this function) want to be seen after the calls to this function outside (and do not want to find out myself---I'd rather want to see somebody else with stakes in "git subtree" to verify), but otherwise the change looks benigh to me. I have no idea if what [3/3] does is sensible or not (and again, I'd rather want to see somebody with stakes to double check). Thanks.