From: Colin Stagner Date: Thu, 16 Apr 2026 01:26:02 GMT Subject: Re: git subtree bugs (mishandled merges, recursion depth) Message-ID: In-Reply-To: <26263.63341.878041.155047@chiark.greenend.org.uk> Hello Ian, does this git-subtree issue still affect you? On 7/17/24 11:55, Ian Jackson wrote: > Steps to reproduce: > > git clone https://gitlab.torproject.org/tpo/core/arti.git > cd arti > git checkout 01d02118cdda30636e606fc1a89b3e04f28b8ad1 > git subtree split -P maint/rust-maint-common > > Actual behaviour (git 2.45.2, Debian amd64 1:2.45.2-1 .deb): > > $ git subtree split -P maint/rust-maint-common > /usr/lib/git-core/git-subtree: 318: Maximum function recursion depth (1000) reached > $ On Debian's POSIX sh, shell recursion is artificially limited to 1000 calls. This is not typical behavior; most distros I've tested do not cap it. bash has a configurable recursion depth limit, but sh ignores it. I've proposed a fix for the recursion depth issue in: If you have the time, I'd appreciate some testing and/or a code review. > Expected behaviour: > > The resulting history ought to have a few dozen commits, > most of which are the upstream history of the subtree. > Actual behaviour (git 2.20.1, Debian ancient 1:2.20.1-2+deb10u9): > > Takes a very long time. Everntually produces an output commit > which has most of arti.git#main in its history. Even with my patch series applied, there are many more than a "few dozen commits" in the history. For me this splits as 9a2422685e6cc05625f47a1fe709f1908f31fc87 with 12307 commits in the history graph. The reason for this is likely e7b07376e5 (Merge branch 'rs/subtree-fixes', 2018-10-26), which was merged around that time. Previous versions discarded too much history, and that patch series added more merge-base ancestry checks. When merges come into play, the task of choosing which history is "important" and which history is "not important" is not always clear-cut. Colin