From: Colin Stagner <ask+git@howdoi.land>
Date: Mon, 26 Jan 2026 05:14:25 GMT
Subject: Re: [regression][bisected] git-subtree remote desynchronization
Message-ID: <023ae712-8f67-441c-aada-fb5b097ec617@howdoi.land>
In-Reply-To: <xmqqecnel2fs.fsf@gitster.g>

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)