[regression][bisected] git-subtree remote desynchronization

[regression][bisected] git-subtree remote desynchronization

[Christian Heusel]

[-- Attachment #1: Type: text/plain, Size: 4713 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [regression][bisected] git-subtree remote desynchronization

[Junio C Hamano]

Christian Heusel <christian@heusel.eu> writes:


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

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.

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

Re: [regression][bisected] git-subtree remote desynchronization

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> 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.

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

Re: [regression][bisected] git-subtree remote desynchronization

[Colin Stagner]

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

> Unless a fix materializes and gets verified before -rc2 (scheduled for
> coming Tuesday), we should revert the merge of the problematic
> topic.
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,

> Repeated splits of exactly the same history are guaranteed to be
> identical as long as the settings passed to split are the same.

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:

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

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)

Re: [regression][bisected] git-subtree remote desynchronization

[Christian Heusel]

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

On 26/01/25 11:14PM, Colin Stagner wrote:
> <snip>
> 
> On 1/24/26 05:43, Christian Heusel wrote:
> 
> > 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
> >     ```
> 
> 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?

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.

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

Thanks for investigating this, your work is really appreciated!

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

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

> [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)

Cheers,
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [regression][bisected] git-subtree remote desynchronization

[Colin Stagner]

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

> On 26/01/25 11:14PM, Colin Stagner wrote:
>> 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.
> 
> I guess that is for you and Junio to judge, but rushing a fix sounds
> like unneccesary risk for an optimization.

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

Re: [regression][bisected] git-subtree remote desynchronization

[Junio C Hamano]

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

> On 1/24/26 22:51, Junio C Hamano wrote:
>
>> Unless a fix materializes and gets verified before -rc2 (scheduled for
>> coming Tuesday), we should revert the merge of the problematic
>> topic.
> 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.

Done.  Thanks.