Make repo-level merging rebase descendants of rewritten/abandoned commits

[martinvonz]

Let's say you have commit A, which you rewrite as A'. You then add commit B on top. You then realize you want to undo the A->A' operation. Undoing that currently results in divergence because you get A back but A' is still visible because B is on top of it. I think we should rebase B onto A instead.

Another case is when you have pushed a branch to GitHub to create a PR. The PR then gets merged and the branch gets deleted from the remote. When you now jj git fetch from the remote, we pull down the new main branch and delete the old feature branch locally. However, we leave the commits in place and you have to manually abandon them. I think we should instead remove the commits and rebase any commits onto their closest visible ancestor.

These two cases are perhaps not obviously related, but I think they will both implemented in the repo-level merge. That means you'll get the same automatic rebasing from A' to A when you fetch that update from a remote, and the same automatic rebasing to ancestors if you undo an operation that added commits that your new branch is based on.

Note that the interaction with remotes will work much more smoothly once we can preserve Change IDs throughout the roundtrip to a remote. One option for achieving that would be to add the Change ID to the commit message like Gerrit does with its Change-Id: footer. If we do that, we'll want to make it optional so non-Jujutsu users won't be bothered by it. For now, we should do the automatic rebasing when we notice that a branch was moved in Git.

This is something I've meant to do for a year or something, but it's become more important to me personally now that I use GitHub PRs.

[martinvonz]

A related cleanup I've meant to make is to the internal representation of branches and remotes. A branch currently knows where it points locally and on all remotes. I'm hoping to change that so the branch doesn't know about its target on remotes and to instead have a per-remote view object containing the branches on that remote.

After restructuring it like that, I think it will be easier and more natural to implement pull (fetch) as a 3-way repo-level merge: take the local repo's state and apply the diff between the remote's previously recorded state and the remote's new state. The same applies when importing from an underlying Git repo.

I'm documenting these thoughts here in the hope that it's useful to others, so please ask if the above didn't make any sense to you. I'll try to find time to document it in the repo as well some day...