Re: git subtree bugs (mishandled merges, recursion depth)

From: Colin Stagner <ask+git@howdoi.land>
Date: Apr 16, 2026, 01:26 UTC
Message-ID: <e9611b58-3886-4f04-8f49-16d140ebfc15@howdoi.land>
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:

Show 12 quoted lines

> 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:

<https://lore.kernel.org/git/20260305-cs-subtree-split-recursion-v2-0-7266be870ba9@howdoi.land>

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