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

[Colin Stagner <ask+git@howdoi.land>]

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:

<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