From: Colin Stagner <ask+git@howdoi•land>
To: Junio C Hamano <gitster@pobox•com>,
Christian Heusel <christian@heusel•eu>
Cc: git@vger•kernel.org, Christian Hesse <list@eworm•de>
Subject: Re: [regression][bisected] git-subtree remote desynchronization
Date: Sun, 25 Jan 2026 23:14:25 -0600 [thread overview]
Message-ID: <023ae712-8f67-441c-aada-fb5b097ec617@howdoi.land> (raw)
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)
next prev parent reply other threads:[~2026-01-26 5:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-24 11:43 [regression][bisected] git-subtree remote desynchronization Christian Heusel
2026-01-25 2:44 ` Junio C Hamano
2026-01-25 4:51 ` Junio C Hamano
2026-01-26 5:14 ` Colin Stagner [this message]
2026-01-26 14:12 ` Christian Heusel
2026-02-15 21:05 ` Colin Stagner
2026-01-26 17:32 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=023ae712-8f67-441c-aada-fb5b097ec617@howdoi.land \
--to=ask+git@howdoi$(echo .)land \
--cc=christian@heusel$(echo .)eu \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=list@eworm$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox