{"thread":{"id":"64683","subject":"[Bug] Git subtree regression","startedAt":"2025-12-26T20:16:30Z","lastAt":"2026-02-18T04:29:55Z","messageCount":11,"participants":["dev@dietrich.pub","george@mail.dietrich.pub","Colin Stagner","D. Ben Knoble"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"532769","messageId":"176677910605.6.2281395015810449820.1087545551@dietrich.pub","threadId":"64683","inReplyTo":null,"subject":"[Bug] Git subtree regression","fromName":"","fromEmail":"dev@dietrich.pub","sentAt":"2025-12-26T19:58:22Z","receivedAt":"2025-12-26T20:16:30Z","isPatch":false,"sender":{"key":"dev@dietrich.pub","avatar":null},"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\nI use git subtrees to manage the monorepo `https://github.com/athena-framework/athena`.\nWhen using git 2.52.0, I can add a new remote for say the `clock` component via `git remote add clock git@github.com:athena-framework/clock.git`\nThen do a `subtree push` via `git subtree push --prefix=\"src/components/clock\" \"clock\" master`.\n\nWhat did you expect to happen? (Expected behavior)\n\nI expected it to work and say `Everything up-to-date`, because it is up to date.\n\nWhat happened instead? (Actual behavior)\n\nIt fails because of:\n\n```\nTo github.com:athena-framework/clock.git\n ! [rejected]        0efb3d9858e3bfee65165508aeeacc50417c9a99 -> master (non-fast-forward)\nerror: failed to push some refs to 'github.com:athena-framework/clock.git'\nhint: Updates were rejected because the tip of your current branch is behind\nhint: its remote counterpart. If you want to integrate the remote changes,\nhint: use 'git pull' before pushing again.\nhint: See the 'Note about fast-forwards' in 'git push --help' for details.\n```\n\nWhat's different between what you expected and what actually happened?\n\nSeems to be a regression of https://github.com/git/git/commit/83f9dad7d6fb5988b68f80b25bd87c68693195dd as it used to work and now it doesn't.\n\nAnything else you want to add:\n\nI did some initial exploration and it might have something to do with the `clock` component originally being added via `git subtree add --squash`.\nFor another component:\n\n- git 2.51.1: split produces 92 commits, properly connected to original repo history\n- git 2.52.0: split produces 8 commits, disconnected history with a new root\n\nThe `git-subtree-split:` marker in the squash commit body doesn't seem to be honored in 2.52.0.\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.52.0\ncpu: x86_64\nbuilt from commit: 9a2fb147f2c61d0cab52c883e7e26f5b7948e3ed\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nrust: enabled\nlibcurl: 8.17.0\nOpenSSL: OpenSSL 3.6.0 1 Oct 2025\nzlib-ng: 2.2.5\nSHA-1: SHA1_DC\nSHA-256: SHA256_BLK\ndefault-ref-format: files\ndefault-hash: sha1\nuname: Linux 6.18.2-arch2-1 #1 SMP PREEMPT_DYNAMIC Thu, 18 Dec 2025 18:00:18 +0000 x86_64\ncompiler info: gnuc: 15.2\nlibc info: glibc: 2.42\n$SHELL (typically, interactive shell): /bin/bash\n\n\n"},{"id":"532853","messageId":"20251230170719.845029-1-george@mail.dietrich.pub","threadId":"64683","inReplyTo":"176677910605.6.2281395015810449820.1087545551@dietrich.pub","subject":"Re: [Bug] Git subtree regression","fromName":"","fromEmail":"george@mail.dietrich.pub","sentAt":"2025-12-30T17:07:19Z","receivedAt":"2025-12-30T17:07:54Z","isPatch":false,"sender":{"key":"george@mail.dietrich.pub","avatar":null},"body":"---\nI explored this more and think I found the root cause.\nCommit `83f9dad7d6fb5988b68f80b25bd87c68693195dd` changed `should_ignore_subtree_split_commit()` to examine only a commit's own trailers via `git show --format='%(trailers:...)'`.\nThe old code used `git log -1 --grep=...` which had the important side effect of searching through ancestor commits.\n\nIn a multi-subtree monorepo with this topology:\n\n```\n  main:    A---B---M---E    (B = subtree add --squash for subA)\n                  /\n  feature:   C---D          (D = subtree add --squash for subB)\n```\n\nWhen splitting `subA`, commits `C` and `D` from the feature branch should be **ignored** because they belong to a branch that only contains `subB`, not `subA`.\n\n## Old behavior (2.51.1)\n\n`git log -1 --grep=\"git-subtree-dir:\"` on commit `C` would traverse ancestors and find `D`'s subtree markers for `subB`, correctly identifying `C` as belonging to another subtree's branch.\n\n## New behavior (2.52.0)\n\n`git show` on commit `C` finds no trailers (regular commits don't have them), so `C` is **not** ignored.\nThis breaks the split because both parents of the merge `M` are processed, but `C` has no cache entry, leading to disconnected history.\nThus, split operations produce fewer commits than expected with broken parent chains, breaking push/pull workflows to upstream subtree repositories.\n\n## Reproduction\n\nThis can be reproduced via my monorepo: https://github.com/athena-framework/athena\n\n```bash\n# 2.51.1 produces correct result (matches the number of commits in the `athena-framework/clock` repo)\n$ git subtree split --prefix=\"src/components/clock\"\n4ee66f8198b2532110b75a36575e363ccccff47e  # 20 commits, connected to remote\n\n# 2.52.0 produces broken result\n$ git subtree split --prefix=\"src/components/clock\"\n0efb3d9858e3bfee65165508aeeacc50417c9a99  # 7 commits, disconnected\n\n# The commits have identical trees but different parents:\n$ git cat-file -p 4ee66f8198b2532110b75a36575e363ccccff47e\ntree 8333b0cbb2a10528f8c803812af7a8e603e70367\nparent d72f22f28ca5ed57ef3c2df74f0abd5569ac5934  # Connected to 19-commit history\n\n$ git cat-file -p 0efb3d9858e3bfee65165508aeeacc50417c9a99\ntree 8333b0cbb2a10528f8c803812af7a8e603e70367\nparent 81c5dbe70ce26a7758fbe7f87b3ce0704043cfb1  # Only 6 commits, disconnected\n```\n"},{"id":"532973","messageId":"e25b4d76-c1b5-4b6b-ba77-e1e2f7243ce9@howdoi.land","threadId":"64683","inReplyTo":"20251230170719.845029-1-george@mail.dietrich.pub","subject":"Re: [Bug] Git subtree regression","fromName":"Colin Stagner","fromEmail":"ask+git@howdoi.land","sentAt":"2026-01-04T04:52:46Z","receivedAt":"2026-01-04T04:53:08Z","isPatch":false,"sender":{"key":"ask+git@howdoi.land","avatar":null},"body":"Hello, George!\n\nThanks for looking in to this.\n\nOn 12/30/25 11:07, george@mail.dietrich.pub wrote:\n> ---\n> I explored this more and think I found the root cause.\n> Commit `83f9dad7d6fb5988b68f80b25bd87c68693195dd` changed `should_ignore_subtree_split_commit()` to examine only a commit's own trailers via `git show --format='%(trailers:...)'`.\n> The old code used `git log -1 --grep=...` which had the important side effect of searching through ancestor commits.\n\nThe old `--grep=...` approach was introduced as a performance speedup \nfor large splits. I don't believe the original author intended to alter \nthe split result, but the old approach inadvertently did in some cases.\n\n\n> # 2.52.0 produces broken result\n> $ git subtree split --prefix=\"src/components/clock\"\n> 0efb3d9858e3bfee65165508aeeacc50417c9a99  # 7 commits,\n\nOn v2.52.0 on my machine, I get an error instead:\n\n      fatal: could not rev-parse split hash \nd0ed70566b3e962fbff71145d8155986b48c6885 from commit \n5817d4435bf448f526c3b0049f00e6500277e4bb\n\nI presume I need more history than just master to make this work.\n\nCan you test this split command in git v2.43.7? This is before \n`should_ignore_subtree_split_commit()` was introduced.\n\nI'd like to distill this down into a minimum working example that \ndoesn't depend on an external repo like athena. Namely, some shell \ninstructions that start from an empty `git init` and create a repo with \nthe bug condition. That way, we know exactly and narrowly what sort of \nhistory graph produces the bug. I think I have almost enough information \nhere to do that, but you're welcome to try writing an MWE yourself.\n\n> In a multi-subtree monorepo with this topology:\n> \n> ```\n>    main:    A---B---M---E    (B = subtree add --squash for subA)\n>                    /\n>    feature:   C---D          (D = subtree add --squash for subB)\n> ```\n\nJust to verify: in this example, is commit M a normal merge commit? Or \nis it also created with subtree?\n\nColin\n\n\n"},{"id":"532992","messageId":"20260104142733.2334796-1-george@mail.dietrich.pub","threadId":"64683","inReplyTo":"e25b4d76-c1b5-4b6b-ba77-e1e2f7243ce9@howdoi.land","subject":"Re: [Bug] Git subtree regression","fromName":"","fromEmail":"george@mail.dietrich.pub","sentAt":"2026-01-04T14:27:26Z","receivedAt":"2026-01-04T14:28:08Z","isPatch":false,"sender":{"key":"george@mail.dietrich.pub","avatar":null},"body":"---\n\nAhh, yes. It seems you also need to add `clock` as a remote and fetch it:\n```\n$ git clone git@github.com:athena-framework/athena.git\n$ cd athena\n$ git remote add clock git@github.com:athena-framework/clock.git\n$ git fetch clock\n$ git subtree split --prefix=\"src/components/clock\"\n0efb3d9858e3bfee65165508aeeacc50417c9a99\n```\n\nI wasn't able to use _exactly_ 2.43.7, but I was able to use 2.43.0 which would still be before that other change.\nIt also produced the expected commit hash, unlike 2.52.0.\nIt, also was significantly faster, took ~9s vs 2.51.1 which was ~26s.\n2.52.0 was better at ~14s, but of course produces the wrong hash.\n\nThis reproduces the issue quite well, and what the root cause likely.\nIt does seem one component was added differently, as a non-merge commit, which seems break things.\nLooking at the Athena monorepo, this can somewhat be confirmed via https://github.com/athena-framework/athena/commits/master/?after=ee21a41e9dfc969e759b532d45c0c0faa21876d6+0.\nHow the first two commits show up as verified, unlike the other times when I normally do `git subtree add --squash` and push directly to main, they show up as unverified.\n\n```\n#!/bin/bash\n#\n# THE BUG:\n# When a commit's direct parent is a squash commit for a DIFFERENT subtree,\n# and that squash commit's ancestry includes OUR subtree's squash commit,\n# the split breaks.\n#\n# Old code: `git log -1 --grep` searches ancestry, finds our marker → don't ignore\n# New code: only checks parent's own trailers → ignores → breaks parent chain\n#\n# This pattern occurs when subtree squash commits are cherry-picked or rebased\n# into a linear history (instead of the normal merge structure).\n\nset -e\n\nKEEP_TMPDIR=\"${KEEP_TMPDIR:-}\"\n\nTMPDIR=$(mktemp -d)\necho \"Working directory: $TMPDIR\"\n\ncleanup() {\n    if [ -n \"$KEEP_TMPDIR\" ]; then\n        echo \"Preserving temp directory: $TMPDIR\"\n    else\n        rm -rf \"$TMPDIR\"\n    fi\n}\ntrap cleanup EXIT\n\ncreate_repo() {\n    local repo=\"$1\"\n    git init -b main \"$repo\"\n    git -C \"$repo\" config user.email \"test@test.com\"\n    git -C \"$repo\" config user.name \"Test User\"\n    git -C \"$repo\" config log.date relative\n}\n\ncreate_commit() {\n    local repo=\"$1\"\n    local name=\"$2\"\n    (\n        cd \"$repo\"\n        mkdir -p \"$(dirname \"$name\")\"\n        echo \"$name\" > \"$name\"\n        git add \"$name\"\n        git commit -m \"$name\"\n    )\n}\n\ncd \"$TMPDIR\"\n\necho \"=== Creating repositories ===\"\n\ncreate_repo monorepo\ncreate_repo subA\ncreate_repo subB\n\necho \"=== Creating upstream commits ===\"\n\ncreate_commit subA subA1\ncreate_commit subA subA2\ncreate_commit subB subB1\ncreate_commit subB subB2\n\necho \"=== Setting up monorepo with linear squash structure ===\"\n\n# Initial commit\ncreate_commit monorepo main1\n\n# Add subA with --squash (normal way - creates merge)\ngit -C monorepo fetch ../subA HEAD\ngit -C monorepo subtree add --prefix=subA --squash FETCH_HEAD\n\n# Make a change in subA\ncreate_commit monorepo subA/change1\n\n# Now we simulate cherry-picking JUST the squash commit for subB\n# (This is what seems to have happened in the athena repo)\n# First, get subB ready\ngit -C monorepo fetch ../subB HEAD\n\n# Create a LINEAR squash commit for subB (simulating cherry-pick of just the squash commit)\n# This is the key pattern that triggers the bug - a squash commit as a regular linear commit\n(\n    cd monorepo\n    mkdir -p subB\n    git -C ../subB archive HEAD | tar -x -C subB\n    git add subB\n    # Create a squash-style commit with subtree trailers but as a LINEAR commit\n    # Trailers must be in the last paragraph, separated by blank line\n    subB_short=$(git -C ../subB rev-parse --short HEAD)\n    subB_full=$(git -C ../subB rev-parse HEAD)\n    git commit -F - <<EOF\nSquashed 'subB/' content from commit $subB_short\ngit-subtree-dir: subB\ngit-subtree-split: $subB_full\nEOF\n)\n\necho \"\"\necho \"=== Key structure: subB squash is a LINEAR commit, not a merge ===\"\ngit -C monorepo log -1 --format='%H %s' HEAD\necho \"Parent count: $(git -C monorepo cat-file -p HEAD | grep -c '^parent')\"\n\n# Now make a commit that touches subA\n# This commit's parent is the subB squash commit (linear)\ncreate_commit monorepo subA/change2\n\necho \"\"\necho \"=== Repository structure ===\"\ngit -C monorepo log --oneline --graph\n\n# Verify the squash commit's ancestry includes subA's marker\nsubB_squash=$(git -C monorepo rev-parse HEAD^)\necho \"\"\necho \"=== Checking ancestry of subB squash commit ($subB_squash) ===\"\necho \"Looking for subA marker in ancestry...\"\nif git -C monorepo log -1 --grep=\"git-subtree-dir: subA\" \"$subB_squash\" --oneline 2>/dev/null; then\n    echo \"  FOUND - old code would search this and NOT ignore\"\nelse\n    echo \"  NOT FOUND - test setup may be incomplete\"\nfi\n\necho \"\"\necho \"=== Running subtree split on subA ===\"\n\nsplit_hash=$(git -C monorepo subtree split --prefix=subA 2>/dev/null)\necho \"Split hash: $split_hash\"\n\nsplit_count=$(git -C monorepo rev-list --count \"$split_hash\")\necho \"Commits in split: $split_count\"\n\necho \"\"\necho \"=== Split history ===\"\ngit -C monorepo log --oneline \"$split_hash\"\n\necho \"\"\necho \"=== Result ===\"\n\n# Expected: 4 commits (2 upstream + 2 local changes)\nif [ \"$split_count\" -ge 4 ]; then\n    echo \"PASS: Split produced connected history ($split_count commits)\"\n    exit 0\nelse\n    echo \"FAIL: Split produced disconnected history (only $split_count commits, expected >= 4)\"\n    exit 1\nfi\n```\n"},{"id":"533009","messageId":"4a9c1a5f-336a-472c-af1d-7011fad776a6@howdoi.land","threadId":"64683","inReplyTo":"20260104142733.2334796-1-george@mail.dietrich.pub","subject":"Re: [Bug] Git subtree regression","fromName":"Colin Stagner","fromEmail":"ask+git@howdoi.land","sentAt":"2026-01-05T03:36:13Z","receivedAt":"2026-01-05T03:36:28Z","isPatch":false,"sender":{"key":"ask+git@howdoi.land","avatar":null},"body":"On 1/4/26 08:27, george@mail.dietrich.pub wrote:\n\n> It does seem one component was added differently, as a non-merge commit, which seems break things.\n\n> ```\n> # Create a LINEAR squash commit for subB (simulating cherry-pick of just the squash commit)\n> # This is the key pattern that triggers the bug - a squash commit as a regular linear commit\n> (\n>      cd monorepo\n>      mkdir -p subB\n>      git -C ../subB archive HEAD | tar -x -C subB\n>      git add subB\n>      # Create a squash-style commit with subtree trailers but as a LINEAR commit\n>      # Trailers must be in the last paragraph, separated by blank line\n>      subB_short=$(git -C ../subB rev-parse --short HEAD)\n>      subB_full=$(git -C ../subB rev-parse HEAD)\n>      git commit -F - <<EOF\n> Squashed 'subB/' content from commit $subB_short\n> git-subtree-dir: subB\n> git-subtree-split: $subB_full\n> EOF\n> )\n> ```\n\nYes, this is very likely to cause breakage.\n\nNormally,\n\n     git subtree merge -P subA --squash\n\nmakes two commits, in this order:\n\n1. Squashed 'subA/' content from commit f00...\n2. Merge commit (1) as 'subA'\n\nCommit 1 updates the subtree but does *not* rewrite paths. If you `git \nshow` one, you will see that it has files like\n\n     subA1\n     subA2\n\nand *not* subA/subA1.\n\nThe path rewrite actually takes place in Commit 2 (the merge), via the \n`-Xsubtree` merge strategy option.\n\n`should_ignore_subtree_split_commit` tries to search for commits like \n(1), which all have the `git-subtree-*` trailer. Normally, these commits \neither have:\n\n* no parents, if they result from a new `git subtree add --squash`; OR\n\n* only parents which are also \"Squashed 'subA/' content,\" if\n   they result from a follow-up `git subtree merge --squash`\n\nWe can safely ignore these commits—and all of their parents—during a \n`subtree split` if they belong to a different subtree.\n\nOf course, that heuristic doesn't work if the commit has been rebased \nonto other unrelated history—which is what happened in your repo.\n\nI suspect the best way out may be to remove the \n`should_ignore_subtree_split_commit` heuristic entirely. It is mostly \nuseful for repos that use `split --rejoin` a lot, and the check itself \nis slow. WDYT?\n\n\n> How the first two commits show up as verified, unlike the other times when I normally do `git subtree add --squash` and push directly to main, they show up as unverified.\n\ngit v2.51.0 also adds --gpg-sign compatibility to subtree. Perhaps this \nis what you are seeing?\n\n\n> It seems you also need to add `clock` as a remote and fetch it:\n\nAh, thanks.\n\nPersonally, I'm a big advocate for the monorepo layout. In my \nexperience, it makes almost every task easier and faster.\n\nColin\n\n"},{"id":"533094","messageId":"20260106045528.2628818-1-george@mail.dietrich.pub","threadId":"64683","inReplyTo":"4a9c1a5f-336a-472c-af1d-7011fad776a6@howdoi.land","subject":"Re: [Bug] Git subtree regression","fromName":"","fromEmail":"george@mail.dietrich.pub","sentAt":"2026-01-06T04:55:28Z","receivedAt":"2026-01-06T04:56:04Z","isPatch":false,"sender":{"key":"george@mail.dietrich.pub","avatar":null},"body":"> I suspect the best way out may be to remove the `should_ignore_subtree_split_commit` heuristic entirely.\n> It is mostly useful for repos that use `split --rejoin` a lot, and the check itself is slow. WDYT?\n\nI think this sound reasonable yea. Should be sure to include a spec to capture this case going forward too ofc.\nThis would at least fix the breaking change, and some other heuristic could be applied in the future.\n\n> git v2.51.0 also adds --gpg-sign compatibility to subtree.\n> Perhaps this is what you are seeing?\n\nHmm, I don't think so as I'm just learning about this now.\nWill give it a shot next time I have to add another component tho!\n"},{"id":"533462","messageId":"5794d99e-a7e6-4258-9a1c-1512c3f577af@howdoi.land","threadId":"64683","inReplyTo":"20260106045528.2628818-1-george@mail.dietrich.pub","subject":"Re: [Bug] Git subtree regression","fromName":"Colin Stagner","fromEmail":"ask+git@howdoi.land","sentAt":"2026-01-10T01:25:57Z","receivedAt":"2026-01-10T01:26:22Z","isPatch":false,"sender":{"key":"ask+git@howdoi.land","avatar":null},"body":"George,\n\nCan you have a look at the patch in \n<20260110011811.788219-1-ask+git@howdoi.land> and see if it solves this \nissue?\n\nColin\n\n\n"},{"id":"533496","messageId":"20260110172219.125762-1-george@mail.dietrich.pub","threadId":"64683","inReplyTo":"5794d99e-a7e6-4258-9a1c-1512c3f577af@howdoi.land","subject":"Re: [Bug] Git subtree regression","fromName":"","fromEmail":"george@mail.dietrich.pub","sentAt":"2026-01-10T17:22:19Z","receivedAt":"2026-01-10T17:22:43Z","isPatch":false,"sender":{"key":"george@mail.dietrich.pub","avatar":null},"body":"I did! Thank you so much! It seems it not only produces the correct commit hash but is also quite a bit more performant.\n\n```sh\n$ git --version\ngit version 2.51.1\n\n$ time git subtree split --prefix=\"src/components/clock\"\n4ee66f8198b2532110b75a36575e363ccccff47e\n\nreal    0m32.971s\nuser    0m18.856s\nsys     0m14.627s\n\n$ git --version\ngit version 2.52.0\n\n$ time git subtree split --prefix=\"src/components/clock\"\n0efb3d9858e3bfee65165508aeeacc50417c9a99\n\nreal    0m18.680s\nuser    0m7.698s\nsys     0m12.842s\n\n$ /home/george/dev/git/git/git --version\ngit version 2.52.0.408.gecb62f5599\n\n$ time /home/george/dev/git/git/git subtree split --prefix=\"src/components/clock\"\n4ee66f8198b2532110b75a36575e363ccccff47e\n\nreal    0m10.816s\nuser    0m3.909s\nsys     0m7.755s\n```\n\nThanks again!\n"},{"id":"536073","messageId":"8d5212b5-3088-4b73-a849-f1c297e06157@howdoi.land","threadId":"64683","inReplyTo":"20260110172219.125762-1-george@mail.dietrich.pub","subject":"Re: [Bug] Git subtree regression","fromName":"Colin Stagner","fromEmail":"ask+git@howdoi.land","sentAt":"2026-02-15T20:36:39Z","receivedAt":"2026-02-15T20:36:52Z","isPatch":false,"sender":{"key":"ask+git@howdoi.land","avatar":null},"body":"George,\n\nMy original patch for this issue introduced other regressions and needed \nto be reverted. I don't recommend using it.\n\nInstead, can you take a look at:\n\n  \nhttps://lore.kernel.org/git/20260215201748.889866-1-ask+git@howdoi.land/\n\nwhich removes the \"ignore other splits\" optimization altogether. After \nsome research, I suspect that this optimization may not have enough \ninformation to work correctly and preserve history in all cases.\n\nI'd also appreciate testing of\n\n  \nhttps://lore.kernel.org/git/20260215201748.889866-1-ask+git@howdoi.land/\n\nwhich fixes a \"recursion depth exceeded\" bug on Debian/Ubuntu.\n\nI've CC'd you on both of these patch series.\n\nI have tested both of these on selected subdirectories of your athena \nrepository. They seem to work. But I'd appreciate it if you could look \nat all the splits you normally do and see if the patches correctly \npreserve history for you.\n\nThanks,\n\nColin\n\n"},{"id":"536134","messageId":"CALnO6CDkeBCi3jhHVDG5T2Em_SJrDokezjrao6xCXtSK89MpEw@mail.gmail.com","threadId":"64683","inReplyTo":"8d5212b5-3088-4b73-a849-f1c297e06157@howdoi.land","subject":"Re: [Bug] Git subtree regression","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-02-16T21:25:42Z","receivedAt":"2026-02-16T21:25:54Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Mon, Feb 16, 2026 at 3:26 PM Colin Stagner <ask+git@howdoi.land> wrote:\n>\n> George,\n>\n> My original patch for this issue introduced other regressions and needed\n> to be reverted. I don't recommend using it.\n>\n> Instead, can you take a look at:\n>\n>\n> https://lore.kernel.org/git/20260215201748.889866-1-ask+git@howdoi.land/\n[snip]\n> https://lore.kernel.org/git/20260215201748.889866-1-ask+git@howdoi.land/\n>\n> which fixes a \"recursion depth exceeded\" bug on Debian/Ubuntu.\n>\n> I've CC'd you on both of these patch series.\n\nJFYI: looks like you pasted the same link twice ;)\n\n-- \nD. Ben Knoble\n"},{"id":"536245","messageId":"20260218042918.330374-1-george@mail.dietrich.pub","threadId":"64683","inReplyTo":"8d5212b5-3088-4b73-a849-f1c297e06157@howdoi.land","subject":"Re: [Bug] Git subtree regression","fromName":"","fromEmail":"george@mail.dietrich.pub","sentAt":"2026-02-18T04:29:18Z","receivedAt":"2026-02-18T04:29:55Z","isPatch":false,"sender":{"key":"george@mail.dietrich.pub","avatar":null},"body":"Ahh bummer, thanks for the follow up. I'm on arch and don't seem to suffer from the same recursion limitation as debian/ubuntu do. Because of that I'll defer checking out that set of patches to someone else.\n\nI did however checkout the other and can confirm it looks good! I went thru each of the components and asserted the split hash matches the latest commit on each of the related repos. Also asserted `subtree push` results in an `Everything up to date` message. Thanks again for all your work on this.\n"}]}