BUG: multiple changesets created after running certain commands

[XavierChanth]

Description

Certain jj commands seem to create multiple new changesets, I suppose ones that do something, then automatically create a new changeset for you afterwards.

I have observed this with jj git push and some other commands (I cannot say for certain which yet).

I apologize if there is another issue open, I looked for duplicates but could not find any.

Steps to Reproduce the Problem

1. Make a change
2. jj desc
3. jj bookmark set trunk
4. jj git push

Expected Behavior

Only one new changeset is created.

Actual Behavior

Multiple new changesets are being created:

The change I made was at r, this is the changeset I ran the commands from.
Here is the log afterwards:

   1   @  lkokuosw XavierChanth 1 minute ago 7fcea05f
   2   │  (empty) (no description set)
   3   │
   4   │ ○  zrsnuykk XavierChanth 1 minute ago c0a20d52
   5   ├─╯  (empty) (no description set)
   6   │
   7   ◆  rrsnquvz XavierChanth 1 minute ago trunk git_head() 1734ac29
   8   │  macos dock defaults
   9   ~

As you can see, it created z and l. I typically have solved this by running
jj edit z which abandons l. When I am working on complicated changesets, like taking several dependent changes and separating them into stacked branches for PRs, I have racked up like 5 or 6 of these extra changes.

I have also observed this behavior with other jj commands, I think either squash or split, but I was unable to reproduce an example. I did not run any bookmark set or git push commands at the times that I observed the behavior, so it definitely affects other commands, but I cannot say for certain what they are.

I'll observe my commands and update this ticket if I encounter more reproducible scenarios.

Specifications

• Platform: macos arm64
• Version: jj 0.24.0

uname -a:

Darwin hostname-omitted 24.1.0 Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000 arm64

[XavierChanth]

Here's another scenario with rebase:

The graph starts with these two changes:

○  zrsnuykk XavierChanth 10:13 12/14/24
│  git_head() 25da2a68
│  (no description set)
│
◆  rrsnquvz XavierChanth 09:55 12/14/24
│  trunk 1734ac29
~  macos dock defaults

Then I ran:
jj new -r r
It created change m.

Then I ran jj rebase -s z -d m

And here's the graph:

@  mxkqttvy XavierChanth 10:13 12/14/24
│  9e116c7d
│  (no description set)
│
│ ○  mqxrmkvy XavierChanth 10:13 12/14/24
├─╯  655dab00
│    (no description set)
│
○  zrsnuykk XavierChanth 10:13 12/14/24
│  git_head() 25da2a68
│  (no description set)
│
◆  rrsnquvz XavierChanth 09:55 12/14/24
│  trunk 1734ac29
~  macos dock defaults

change m got duplicated into mq and mx.

[XavierChanth]

I was using rebase -s when I encountered the scenario with 5 or 6 duplicates now that I think about it.

[martinvonz]

You can use jj op log avd jj log --at-op to figure out which operation added the commits.

[XavierChanth]

You can use jj op log avd jj log --at-op to figure out which operation added the commits.

I'm struggling to reproduce now, but the next time I encounter the bug, I will capture that information.

[martinvonz]

It's already captured. You can run those commands now to troubleshoot.

[XavierChanth]

It's already captured. You can run those commands now to troubleshoot.

Captured in a gist, since it's quite long:

https://gist.github.com/XavierChanth/50f0f9f0e0061725c58768989dfcf591

It it normal to see the snapshot of the working copy diverge from the rebase? It seems like that should be linear.

[martinvonz]

Ah, that looks like a known bug that we should take a lock on the working copy while importing git refs. It's related to the nvim integration that runs in the background and snapshots the working copy. We have this TODO for it:

jj/cli/src/cli_util.rs

Lines 1054 to 1062 in ef724d2

	// TODO: There are various ways to get duplicated working-copy
	// commits. Some of them could be mitigated by checking the working-copy
	// operation id after acquiring the lock, but that isn't enough.
	//
	// - moved HEAD was observed by multiple jj processes, and new working-copy
	// commits are created concurrently.
	// - new HEAD was exported by jj, but the operation isn't committed yet.
	// - new HEAD was exported by jj, but the new working-copy commit isn't checked
	// out yet.

(I think I misunderstood what you meant by "capture" before, btw. I thought you were talking about capturing the bad state, but you might have been talking about capturing it from the terminal and sharing it here.)

[XavierChanth]

Yes, that is what I meant by capture, sorry for the confusion.

I did build a little plugin in nvim that shows jj log next to an embedded terminal.

It seems this issue can be closed since it's already being tracked. I'll defer to you in case you want to leave it open until it's resolved.