Related improvements in future Git (based on merge-ort)

[krobelus]

I've been reading Elijah Newren's blog posts on optimizing git's merge implementation. To enable the optimizations, they added the new "ort" merge backend.
Crucially, it can merge without touching the working tree or index. These two commit messages are nice reads:

• gitster/git@fe1a21d526 (fast-rebase: demonstrate merge-ort's API via new test-tool command, 2020-10-29)
• gitster/git@6a5fb96672 (Change default merge backend from recursive to ort, 2021-08-04)

This sounds like we're one step closer to getting some of git-revise's features in core git.

git-rebase (and git cherry-pick) should move towards only touching the worktree when needed, as this comment suggests.
If that becomes reality one day, the main difference is conflict resolution (with git-revise using a temporary file (?).

---

Another difference is that git-revise never reparents a branch (i.e. it does not add new commits from upstream).
Maybe it makes sense to split git rebase into git rebase (for reparenting) and git revise (for history modification), like reset/checkout split off restore/switch. Ofc that's another discussion on the Git project.

---

I just discovered git merge-tree which has apparently always been able to merge without touching index/worktree; I wonder if this is powerful enough to replace our use of git merge-file. (I'm not sure what's the difference to the ort merge, probably this one doesn't detect renames etc.),
git merge-tree can't change commit messages, so it's not usable for git-revise.

[arxanas]

I believed I looked at git-merge-tree for git-branchless and decided I couldn't use it. My understanding was that it wouldn't work well for rebases, because you can only specify a single base commit, but you would want to use different bases. I might be wrong, though.

EDIT: see below, I was mistaken.

[krobelus]

I believe if you want to merge a bunch of commits, then having one "merge base" (the common ancestor) is enough, no need for more.
git merge-tree can't do octopus merges (that merge more than two commits) but that's accepable.

[arxanas]

What I was talking about is what Elijah is referring to in this comment in this article, regarding a "funny merge base":

Rebasing and cherry-picking is also a merge operation for each commit being transplanted (using a funny merge base), but the resulting commit is written with a single parent instead of as a merge commit.

So it's not that you don't need multiple bases, but the merge-base needs to be the parent commit of the commit to be rebased. This often isn't an ancestor of the destination commit at all!

That is, in this diagram:

o A
|
o B
|\
| o C <-- this is the merge-base...
| |
| o D <-- ...if you want to rebase this commit...
|
o E <-- ...on top of this one.

If you want to rebase D on top of E, then you want the merge-base to be C, rather than the common ancestor of D and E.

But it looks like I was mistaken anyways. For some reason, I thought that you needed two different base commits to compare against: one for the source commit, and one for the destination commit. This isn't the case, as you only need one base commit. It just might not be a common ancestor of the two commits.

It seems that you can specify whatever base tree you want for the first argument to git-merge-tree, so there's no problem.

[krobelus]

oh wow, thanks for the clarification!