Small documentation change on rebase.rs

[jonathantanmy2]

Updated the PR to only contain a comment describing existing behavior.

Why I'm not autosubmitting: @Caleb-T-Owens could you take a look? These look reasonable to me but I just wanted a second opinion, especially 'rebase: "our" is target, "their" is incoming '. The rationale for both changes are in their respective commit messages.

There are some test differences that I don't quite understand, but note how in conflicting_merge, the results now match the comments.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
gitbutler-web	Ignored	Preview	Feb 25, 2026 6:51pm

[Caleb-T-Owens]

Hi!

There are semantics around how we cherry-pick conflicted commits that expect the "theirs" tree to represent the user's content. If we wanted to swap tree usage, we would need to update all the locations where we write conflicted commits and all the places where we cherry-pick conflicted commits, along with some form of backward compatibility.

For now, I'd suggest updating the comments and leaving the tree writing as is.

[jonathantanmy2]

There are semantics around how we cherry-pick conflicted commits that expect the "theirs" tree to represent the user's content.

Ah thanks. Do you know offhand where in the code this is enforced? I tried looking and the closest I got was in crates/but-rebase/src/cherry_pick.rs commit_from_conflicted_tree() but there doesn't seem to be anything there that states that "theirs" is the user's content.

[jonathantanmy2]

For now, I'd suggest updating the comments and leaving the tree writing as is.

I took a further look and it seems that the parent IDs are written in the form I would expect, but the trees are swapped. Like you said, I don't think we can swap the trees to the order I would expect (swapping the parents to match the trees is out of the question, I believe). I've updated the PR to only document the existing behavior.