How to rebase a merge commit? Also, strange divergence.

[ilyagr]

Here is my situation:

@ 9b7227276f94 7343b9b321bd [email protected] 2022-09-11 12:28:10.000 -07:00 dim-preview-cursor
| Respect inactive cursor for empty directories
| o 20c2d988e76c bee2bfe6c83c [email protected] 2022-09-04 11:52:48.000 -07:00 focus-fixes
| | Trying to fix focus bug in command mode
| o-.   8baf6ec46768 c014cf4a03c9 [email protected] 2022-08-30 00:13:16.000 -07:00
| |\ \  Merge pull requests into ilya
|/ / /
o | | 0b1e970d9e49 976d6492ac15 [email protected] 2022-08-29 22:18:53.000 -07:00 dim-preview-cursor@origin   HEAD@git
~/ /  No-op changes to ui.go
o | dd5dc591c4d4 8caf9f43cd3f [email protected] 2022-08-29 23:45:57.000 -07:00 minor-fixes
~/  Minor corrections
o 13ff4305a352 47dd6788489f [email protected] 2022-08-28 15:16:21.000 -07:00
~ Merge branch 'laktak__on-select' into ilya

Here, I just added commit 9b722, and I now want to rebase the (non-trivial) merge commit 8baf on top of it.

I tried jj rebase -s 8baf -d @ -d dd5d -d 13ff. This worked well, but resulted in the merge commit becoming "divergent", which I'm not sure how to solve:

o 09acb445ba63 bee2bfe6c83c [email protected] 2022-09-04 11:52:48.000 -07:00 focus-fixes
| Trying to fix focus bug in command mode
o-.   e33bc4fcedc4 c014cf4a03c9 [email protected] 2022-08-30 00:13:16.000 -07:00    divergent
|\ \  Merge pull requests into ilya
@ | | 9b7227276f94 7343b9b321bd [email protected] 2022-09-11 12:28:10.000 -07:00 dim-preview-cursor
| | | Respect inactive cursor for empty directories
o | | 0b1e970d9e49 976d6492ac15 [email protected] 2022-08-29 22:18:53.000 -07:00 dim-preview-cursor@origin   HEAD@git
~/ /  No-op changes to ui.go
o | dd5dc591c4d4 8caf9f43cd3f [email protected] 2022-08-29 23:45:57.000 -07:00 minor-fixes
~/  Minor corrections
o 13ff4305a352 47dd6788489f [email protected] 2022-08-28 15:16:21.000 -07:00
~ Merge branch 'laktak__on-select' into ilya

My questions are:

1. What is the best way to do the original rebase I tried?

   As an aside, the fact that rebase with multiple -d mostly works is really neat, but not documented anywhere.

2. Is the divergent condition expected in this situation, or is it a bug? I'm not sure, but I find it unexpected.

   Another aside

   For simplicity's sake, I did not include two commits I had in between the merge commit and the tip of `focus-fixes` branch. After the rebase, these two commits also were divergent, but the tip of the branch wasn't for some reason, looking like this:

   o 09acb445ba63 bee2bfe6c83c [email protected] 2022-09-04 		11:52:48.000 -07:00 focus-fixes
   | Trying to fix focus bug in command mode
   o e46e15e30a2c 3715a209bf48 [email protected] 2022-09-01 19:21:58.000 -07:00 ilya-new   divergent
   | Stop focus events when launching programs
   o a6af1e64366e 5f8827b378a9 [email protected] 2022-08-30 00:15:27.000 -07:00    divergent
   | When losing focus, dim cursors instead of removing them
   o-.   e33bc4fcedc4 c014cf4a03c9 [email protected] 2022-08-30 00:13:16.000 -07:00    divergent
   |\ \  Merge pull requests into ilya
   

3. How do I recover from the divergent condition?

None of this is urgent, jj and git provide me with plenty of tools to fix this manually if I want to.

P.S. Here is the repo in the divergent state: lf_repo2.tgz. It's a slightly newer version of the repo I uploaded in the other discussion.

[ilyagr]

An update: after I did a git push of the "divergent" revisions, and jj imported the result, there is no more divergence. I guess it was the branch that was diverging from its remote version.

So, I now think I misunderstood the concept and this is working as expected. This is merely a documentation bug (or I missed some documentation).

[martinvonz]

What is the best way to do the original rebase I tried?

What you did is correct. I'm glad you figured that out :) Good point about documenting it. Fixed in #536 (as you know).

Is the divergent condition expected in this situation, or is it a bug? I'm not sure, but I find it unexpected.

I suspect that's a bug in the automatic export to Git that happens when you run jj and Git in a shared working copy (i.e. when .jj/ and .git/ are siblings). I know the export doesn't happen as it should there. We export any changes that happened while running the jj command, but we don't update our internal record of where it is in Git. If you then rewrite the ref using Git and then run jj again, it'll think that the reference was updated from the point before the earlier jj command and you'll get a conflict in the branch. I suspect it's something similar that happened here. If you run jj log --at-op f27ee90791f1, you can see that the output looks correct right after the rebase. It's only after the next operation (02731834c4dd - an automatic import from Git) that you get divergent commits because the old commit becomes visible again.

Sorry to not have a better answer. I'll try to prioritize fixing that bug we have when exporting refs to Git because it's one of the more common and annoying ones. @chooglen, let me know if you wanted to fix that bug since I know we talked about it before.

An update: after I did a git push of the "divergent" revisions, and jj imported the result, there is no more divergence. I guess it was the branch that was diverging from its remote version.

When you ran the rebase command, it should have hidden the commit that the remote pointed to and it shouldn't have become visible again, so I do think there was a bug.

PS. You can add ui.color = "always" to your ~/.jjconfig.toml if you always want it enabled (looks like it from recent operation log entries). I think you need to make that [ui]\ncolor = "always" if you already have some tables in the file.

[chooglen]

@chooglen, let me know if you wanted to fix that bug since I know we talked about it before.

I pretty much don't mind fixing any bug, but don't let me stop you :)

IIRC, "that bug" is that jj doesn't update its view of the Git repo before exporting (including branches, anonymous heads, etc)? So this is bigger than #490, which is only about telling jj which commits got rewritten to which in Git land.

[martinvonz]

I pretty much don't mind fixing any bug, but don't let me stop you :)

Sounds good, I'll let you know if I start working on it.

IIRC, "that bug" is that jj doesn't update its view of the Git repo before exporting (including branches, anonymous heads, etc)?

Correct, that's what I suspect is the root cause here even though I don't quite understand what made the old branch location visible again.