[Ergonomy] Support for git-like rerere

[LifeIsStrange]

https://delicious-insights.com/en/posts/git-rerere/
Git rerere is probably the best git feature for productivity and I wonder if JJ already support such feature, or otherwise wether it's on the roadmap.
Also given that you have interop with git repositories I wonder if you could leverage previous git records to apply after the repository has migrated from git to jj

[arxanas]

I suspect rerere wouldn't be necessary when using jj change-ids. You wouldn't have to resolve conflicts again because the logical change has been tracked and you can skip applying it again.

I suspect rerere might be less useful in a primarily rebase- rather than merge-oriented workflow? I never have to use rerere, I think because I always rebase my changes instead of merging them.

[LifeIsStrange]

I suspect rerere might be less useful in a primarily rebase- rather than merge-oriented workflow?

I don't know for rebase but from experience it is very useful for merge oriented worflows. I did had many redundant conflicts in the past using rebase too but it's possible I was using git rebase in a bad way since the ergonomy was so awful it made me slighly question my usage.

Look I haven't used JJ yet so about

I suspect rerere wouldn't be necessary when using jj change-ids. You wouldn't have to resolve conflicts again because the logical change has been tracked and you can skip applying it again.

I have to trust you on that one, the day I'll decide to experiment with JJ I could share wether it would benefit or not from rerere.

@martinvonz friendly ping

[martinvonz]

I don't know for rebase but from experience it is very useful for merge oriented worflows. I did had many redundant conflicts in the past using rebase too but it's possible I was using git rebase in a bad way since the ergonomy was so awful it made me slighly question my usage.

I have also never really used rerere, but I know reasonably well how it works. There are a few cases where it can be useful. I think jj provides good solutions in the cases I can think of at least. It's the first-class support for conflicts that helps.

Use case: "test merge"

Let's start with the scenario from git help rerere. They have this history:

           o---*---o topic
          /
 o---o---o---*---o---o master

The use case they describe there is to merge master into topic as a "test merge", to see what conflicts there are. The idea is that you'll continue to work on topic afterwards. So they do that test merge and resolve the conflicts, and then undo the merge (using git reset --hard HEAD^1, presumably), because they want to keep history free from "unnecessary" merge commits, i.e. they want to avoid two merge commits like this:

           o---*---o---+---o---o topic
          /           /         \
 o---o---o---*---o---o---o---o---+ master

Then when they've finished working on the topic branch, they merge from master again and rely on rerere to resolve the conflicts. As an alternative, they say you can rebase topic onto master and also benefit from rerere to resolve the conflict.

If you use jj for this use case, you can simply keep the merge until you are done. The conflict resolution thus remains in the merge commit (as it would with git). Then, when the topic branch is complete, you can rebase the merge commit to the end. That rebase would actually rebase the conflict resolution since that's all the merge commit contains (jj defines the change in a commit as the difference compared to the merged parents). Git, on the other hand, actually does not rebase merge commits at all, it simply discards any changes in the merge commit and creates a new merge commit (which is why rerere is useful).

If you instead rebase the branch with jj rebase, you'll end up with something like this:

                               o---*---o---+---o---o topic
                              /
 o---o---o---*---o---o---o---o   master

The commits marked * touch the same area (I copied this notation from git's help text). What you'll see if you look at jj log after that rebase is that the * commit on the topic branch will have a conflict. So will the next commit. The interesting bit is that the next commit (the rebase merge commit, which only has one parent now) will not! That's because it contains the conflict resolution. You can then decide to move the conflict resolution into the commit with the conflict. Let me give names to the commits:

                               I---J---K---L---M---N topic
                              /
 A---B---C---D---E---F---G---H   master

So the conflict is introduced in commit J there, it remains unchanged in commit K, and is fixed in commit L. If you now run jj move --from L --to J, it'll squash the conflict resolution into the conflict-creating commit and all conflicts will be gone. Things like that felt like magic even to me when I first developed it, but it actually does work 😃 See https://asciinema.org/a/HqYA9SL2tzarPAErpYs684GGR (linked from the readme) for an example.

Use case: rebasing "internal" merge commits

Another scenario where rerere is useful is when you have a feature branch with some internal merge commit. Like this:

         M---N
        /     \
       I---J---K---L topic
      /
 A---B---C---D---E---F   master

If you now want to rebase the whole topic branch (with some flavor of --preserve-merges if using git rebase) onto master, you'll have to re-resolve any conflicts between M-N and J that you had previous resolved in K. That's because, as I mentioned earlier, git rebase will simply redo the merge instead of trying to preserve its changes. If you use jj rebase, it just works, thanks to its better understanding of conflicts. By the way, if you had any unrelated changes in commit K (a so called "evil merge"), git rebase would discard those too, while jj rebase would preserve them.

[LifeIsStrange]

@martinvonz Thanks a lot for this very high quality, instructive answer. I should definitely give JJ a try !
I wonder if there are other uses cases for rerere but you have probably analysed the most frequent ones.

[martinvonz]

I spent a few minutes looking for other use cases.

The first one I looked at was this (under "Realistic use case"). There they want to remove some old commit before a merge (like commit B above). That case would be handled very well by first-class conflicts. (Also, it's so much easier to do it with jj abandon B instead of git rebase -i --preserve-merges.)

Most other pages I could find talked about test/control merges like in git help rerere. The only other use case I could find was from the Pro Git Book. The use case mentioned there is when you have lots of pending commit series from different contributors and you, as the project's maintainer, merge them all into a single commit. When you get an updates from a contributor, you want to update rewrite that merge. rerere can then help you resolve those conflicts. If you use jj instead, you can instead rebase the old merge commit (which contains the conflict resolutions) onto the new branches (yes, you can rebase a commit onto multiple commits jj rebase -s <old commit> -d <parent1> -d <parent2> -d <parent3> ...). So git is more automatic and jj is more explicit about which solutions get reused, for better or worse.

By the way, I've seen a few people mention "sharing rerere cache" (example). The solutions feel like hacks to me. With conflict resolutions stored in the commit itself, you can just push it as usual. However, we currently don't allow pushing commits with conflicts since the remote git server (and anyone pulling from it) won't be able to make sense of them. I imagine we'll add a --allow-conflicts flag some day.

[Mic92]

#7057