Checkout takes me to the wrong commit

[ilyagr]

Repo state: jj-repo2.tar.gz

Let me replay what happened when I did jj up f364 starting at the op log point d9a3 in the following op log:

$ jj op log |head -n 6
@ 76fb3d25bef4 ilyagr@hostname 2022-11-01 22:00:57.482 -07:00 - 2022-11-01 22:00:57.484 -07:00
| commit working copy
o 42f90a5f2df5 ilyagr@hostname 2022-11-01 22:00:57.439 -07:00 - 2022-11-01 22:00:57.443 -07:00
| check out commit 2f50b84b3b5fb6c2e8738f0a56fe41276b5ffb25
| args: jj up f364
o d9a3698bafdb ilyagr@hostname 2022-11-01 22:00:42.895 -07:00 - 2022-11-01 22:00:42.899 -07:00

The log looked as follows. I wanted to move to the change f36469, the second one from the top:

$ jj --at-operation d9a36 log
@ c3474a45d565 773713ee00e1 [email protected] 2022-11-01 22:00:21.000 -07:00   
| (no description set)
| o   2f50b84b3b5f f36469cec32b [email protected] 2022-11-01 21:55:13.000 -07:00    conflict
| |\  (no description set)
|/ /  
o | 90c98f8d714c c80f023c66e3 [email protected] 2022-10-30 01:23:45.000 -07:00 config   HEAD@git divergent
| | More config docs
| o 674e00332f2b 7079ca3bc943 [email protected] 2022-11-01 21:51:03.000 -07:00   
| | (no description set)
| o a2e76ca7d0f6 ce92731b654a [email protected] 2022-11-01 21:16:14.000 -07:00 mergetool-premerge  
| : Default to empty output file, option to start with conflict markers

There was only one visible commit in that changeset:

$ jj --at-operation d9a36 log -r f364 
o 2f50b84b3b5f f36469cec32b [email protected] 2022-11-01 21:55:13.000 -07:00    conflict
~ (no description set)

I did jj up f364 at this point. The expected behavior would have been for me to now be on an empty commit on top of f364.

What actually happend is that I ended up on top of the c80f0 commit (third from the top in the log above). At the same time, a commit on top of f364 also was created.

In other words, jj log now looks as follows:

$ jj log | head
@ f98e54e6bde3 773713ee00e1 [email protected] 2022-11-01 22:00:21.000 -07:00    conflict
| (no description set)
| o 52f91eee90ad b0c88fd1ca28 [email protected] 2022-11-01 22:00:57.000 -07:00    conflict
| | (no description set)
| o   2f50b84b3b5f f36469cec32b [email protected] 2022-11-01 21:55:13.000 -07:00    HEAD@git conflict
| |\  (no description set)
|/ /  
o | 90c98f8d714c c80f023c66e3 [email protected] 2022-10-30 01:23:45.000 -07:00 config   divergent
| | More config docs
| o 674e00332f2b 7079ca3bc943 [email protected] 2022-11-01 21:51:03.000 -07:00 

$ jj diff -s # The commit I ended up on is far from empty
M docs/config.md
M docs/config.toml
M lib/src/conflicts.rs
M lib/src/files.rs
M lib/tests/test_conflicts.rs
M src/cli_util.rs
M src/commands.rs
M src/diff_edit.rs

This may (or may not) be related to weird conflicts I'm getting in the mergetool2@origin branch. I kept trying to clear that up, which only seemed to make things worse. Currently, jj branch list shows:

$ jj branch list
... (this is an excerpt) ...
mergetool2 (deleted)
  @origin (conflicted):
  - 16c1c0490368 Note about a more involved parsing commits implementation
  + c33f673bf110 Note about a more involved parsing commits implementation
...

[ilyagr]

It is possible that I put the repository in some completely insane state by now while trying to recover from the previous issues we discussed. The solution may be to kill everything and clone it anew, which I'm fine with. I posted this mainly in case somebody will recognize this as a recent regression. (But I haven't checked whether it's a regression; it's getting late).

[martinvonz]

Interesting! I ran jj log --at-op 42f90a5f2df5 (the operation where you ran jj up f364) and the result looks good there. It's the next operation (76fb3d25bef4) where the working copy changed. That operation was a simple commit of the working copy. That happened just 40 ms after the jj up f364, so it was probably something automated (shell prompt?) that ran it. I'll have to think more about what could have caused the working-copy commit to change parent like that.

The weird conflicts are probably #463, which I'm working on fixing.

It is possible that I put the repository in some completely insane state by now while trying to recover from the previous issues we discussed. The solution may be to kill everything and clone it anew, which I'm fine with. I posted this mainly in case somebody will recognize this as a recent regression. (But I haven't checked whether it's a regression; it's getting late).

That shouldn't be necessary. You can instead remove .jj/repo/git_export_operation_id as a workaround for #463.

[martinvonz]

Oh, the bad working-copy commit has the same change ID (773713ee00e1) as the working-copy commit in operation d9a3698bafdb (just before the jj up f364 operation). So I would guess that the write to the working copy failed for some reason, so we ended up updating the files (or only some of them?) but we didn't succeed in recording that we have updated the working copy to operation 42f90a5f2df5, so the next command you ran there thought the working copy was still where it pointed in operation d9a3698bafdb.

[martinvonz]

Do you remember seeing any error indicating that the update failed? Or did you simply ^C it?

We should fix this case by writing some file indicating that an update of the working copy is in progress, so if we later find that file, we can attempt to finish the update then.

[ilyagr]

Do you remember seeing any error indicating that the update failed? Or did you simply ^C it?

No, I don't remember any error or ^C-s.

[yuja]

Perhaps, this is dup of #1608. The last two operations appear to be fired by concurrent processes, which would be synchronized with the working copy lock.