[regression][bisected] git-subtree remote desynchronization

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

I have upgraded my local git installation from v2.53.0-rc0 to 2.53.0-rc1 and noticed that I can not use my local packaging repository monorepo (via aurpublish) anymore.

The steps for reproduction are the following:

1. Update to the 2.53.0-rc1 git release candidate
2. Clone my monorepo for packages in the Arch User Repository:
   ```
   git clone https://github.com/christian-heusel/aur.git && cd aur
   ```
3. Push changes to one of the contained subtree remotes (this would normally be
   done via `aurpublish google-chrome`):
   ```
   git subtree push -P "google-chrome" ssh://aur.archlinux.org/google-chrome.git master
   ```

What did you expect to happen? (Expected behavior)

There are no changes expected since the repositories are synced after each modification to publish the updates to the AUR: ``` $ git subtree push -P "google-chrome" ssh://aur.archlinux.org/google-chrome.git master git push using: ssh://aur.archlinux.org/google-chrome.git master Everything up-to-date ```

What happened instead? (Actual behavior)

```
$ git subtree push -P "google-chrome" ssh://aur.archlinux.org/google-chrome.git master
git push using:  ssh://aur.archlinux.org/google-chrome.git master
To ssh://aur.archlinux.org/google-chrome.git
 ! [rejected]          70b3d81e370936e96f98d0aba357490b75ade7a9 -> master (non-fast-forward)
error: failed to push some refs to 'ssh://aur.archlinux.org/google-chrome.git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. If you want to integrate the remote changes, use 'git pull'
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
```

What's different between what you expected and what actually happened?

I would expect the `git subtree push` command to stay functionally equivalent and the change mentioned above regresses my workflow. This tool and setup is also not really special as a lot of users within the Arch Linux packaging ecosystem are relying on this workflow.

Anything else you want to add:

I have bisected the issue to the following commit:

    28a7e27cff ("contrib/subtree: detect rewritten subtree commits")

This is my bisection log: ``` $ git bisect start # status: waiting for both good and bad commits # good: [7264e61d87e58b9d0f5e6424c47c11e9657dfb75] Git 2.53-rc0 git bisect good 7264e61d87e58b9d0f5e6424c47c11e9657dfb75 # status: waiting for bad commit, 1 good commit known # bad: [83a69f19359e6d9bc980563caca38b2b5729808c] Git 2.53-rc1 git bisect bad 83a69f19359e6d9bc980563caca38b2b5729808c # bad: [0a5dcc1259fa0c8f5c21352c90b3cd3d43273345] Merge branch 'tb/macos-iconv-workarounds' git bisect bad 0a5dcc1259fa0c8f5c21352c90b3cd3d43273345 # good: [ffae4da0128e035acd1887654c98b4f02785adec] Merge branch 'kh/doc-patch-id' git bisect good ffae4da0128e035acd1887654c98b4f02785adec # good: [6edbb7b1d0b50c70e2af0b5f68b7db0984b10be2] Merge branch 'en/fsck-snapshot-ref-state' git bisect good 6edbb7b1d0b50c70e2af0b5f68b7db0984b10be2 # good: [9813aace1e52765e01e688672cdcdcbe25336ec7] Merge branch 'je/doc-reset' git bisect good 9813aace1e52765e01e688672cdcdcbe25336ec7 # good: [d28124151851e42a3bb92963f5b747ad843f33e0] utf8.c: enable workaround for iconv under macOS 14/15 git bisect good d28124151851e42a3bb92963f5b747ad843f33e0 # bad: [79e3055baba32e2952e6e8994cdcd4fc145ba7f0] Merge branch 'cs/rebased-subtree-split' git bisect bad 79e3055baba32e2952e6e8994cdcd4fc145ba7f0 # bad: [28a7e27cff717e5ef91f7445e6a418068608082d] contrib/subtree: detect rewritten subtree commits git bisect bad 28a7e27cff717e5ef91f7445e6a418068608082d # first bad commit: [28a7e27cff717e5ef91f7445e6a418068608082d] contrib/subtree: detect rewritten subtree commits ```

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info]
git version:
git version 2.53.0.rc0
cpu: x86_64
built from commit: 7264e61d87e58b9d0f5e6424c47c11e9657dfb75
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
rust: enabled
libcurl: 8.18.0
OpenSSL: OpenSSL 3.6.0 1 Oct 2025
zlib-ng: 2.3.2
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
uname: Linux 6.19.0-rc6-1-mainline #1 SMP PREEMPT_DYNAMIC Mon, 19 Jan 2026 06:13:35 +0000 x86_64
compiler info: gnuc: 15.2
libc info: glibc: 2.42
$SHELL (typically, interactive shell): /bin/zsh

[Enabled Hooks] applypatch-msg commit-msg post-applypatch post-checkout post-commit post-merge pre-applypatch pre-commit pre-merge-commit pre-push pre-rebase prepare-commit-msg

Christian Heusel <christian@heusel.eu> writes:

Thanks for noticing and reporting a regression before the change got released in an official release.

If a fix materializes and gets verified before -rc2 (scheduled for coming Tuesday), we should revert the merge of the problematic topic.

Junio C Hamano <gitster@pobox.com> writes:

Oops, sorry for an obvious typo.  "If" -> "Unless", of course.

On 1/24/26 22:51, Junio C Hamano wrote:

Understood and no worries. This is a surprisingly complicated issue, and while I've made progress I don't think I'll have a fix that is mergeable by Tuesday. Feel free to revert as needed.

The "exclude other subtrees" logic was first introduced in 98ba49ccc2 (subtree: fix split processing with multiple subtrees present, 2023-12-01). It was intended as a speed optimization only, but every iteration of this logic—including mine—has changed the `git subtree split` output in at least one practical repo.

I am becoming increasingly convinced that any version of this logic is likely to change someone's `subtree split` history, somewhere. Our tests just don't cover everything that might be out there.

The documentation promises that,

Maybe the safer approach is to gate this logic behind a new CLI option, like "--fast-exclude," "--ignore-other-trees," or something to that effect?

On 1/24/26 05:43, Christian Heusel wrote:

I cannot `git subtree push` to your remote, but I can instead run:

     git subtree split -P 'google-chrome'

which happens internally prior to the push.

Before the bisected patch [1], running this on your aur.git's master branch [2] generates a split commit with hash:

     e6f4613797c0eea5a8939441a1fb58211e9184e0

This is the result you expect, right?

I am also testing the other subtrees of aur.git to make sure none of them change, either. With the patch reverted, none of them appear to.

I have made some progress on a fix, but I have not yet achieved 100% hash equivalence across the board. The bisected patch will likely be reverted while I work on a more permanent solution.

[1]: 28a7e27cff (contrib/subtree: detect rewritten subtree commits, 2026-01-09)

[2]: aur.git@29bfddf (upgpkg: rider-eap 1:261.17801.69-1, 2026-01-24)

On 26/01/25 11:14PM, Colin Stagner wrote:

Yes this is the result that I expect to get.

All these repositories are also public if you want to take a look at them, the HTTPS remote is "https://aur.archlinux.org/google-chrome.git", so you can easily compare the current state to the expected state:

    $ git ls-remote --refs https://aur.archlinux.org/google-chrome.git
    e6f4613797c0eea5a8939441a1fb58211e9184e0	refs/heads/master

This also works equivalently for the other subtrees in that repository.

Thanks for investigating this, your work is really appreciated!

I guess that is for you and Junio to judge, but rushing a fix sounds like unneccesary risk for an optimization.

Cheers, Chris

On 1/26/26 08:12, Christian Heusel wrote:

Chris,

I've CC'd you on some proposed changes to remove the git-subtree "should_ignore_subtree_split_commit" logic.

I have tested both of my patch series [1], [2] against every subdirectory of your aur.git repo [3]. I checked the split of every top-level directory as follows:

     for d in *
     do
       test -d "$d" || continue;
       echo >>split-results "$d  $(git subtree split -P "$d")"
     done

I compared the results to git 2.43.7 and found no changes. I would appreciate some more eyeballs and testing on this series to make sure it doesn't introduce any breakage.

Thanks,

Colin

[1]: 20260215201748.889866-1-ask+git@howdoi.land

[2]: 20260215201906.889951-1-ask+git@howdoi.land

[3]: https://github.com/christian-heusel/aur.git

Colin Stagner <ask+git@howdoi.land> writes:

Done.  Thanks.