jj st suggests I run jj git pull, which jj git says doesn't exist

[zygoloid]

Description

Somehow my trunk branch entered a conflicting state, when I don't think it should have. I checked out the conflict and ran jj st and it suggested I run a command that doesn't appear to exist.

Steps to Reproduce the Problem

1. Have two remotes: origin contains commit X, and upstream contains commit X followed by another commit Y.
2. jj git clone origin, and create some more commits, but don't change trunk
3. jj git fetch --remote upstream

Expected Behavior

No conflict. My local trunk now refers to upstream's trunk.

Actual Behavior

A conflict is reported. After I check out the conflict,jj log shows:

@ hashX hashY [email protected] 2022-07-01 17:56:57.000 -07:00
| (no description set)
| [...]
o hashA hashB [email protected] 2022-07-01 16:49:51.000 -07:00 trunk trunk@origin?  
: New commit from upstream
: [...]
o hashC hashD [email protected] 2022-06-28 13:49:38.000 -07:00
~ Old commit from origin and upstream

jj branch list shows:

[...]
trunk: hashA New commit from upstream
  @origin (conflicted):
  - hashC Old commit from origin and upstream
  + hashA New commit from upstream

and jj st says:

Parent commit: hashA New commit from upstream
Working copy : hashX (no description set)
These remote branches have conflicts:
  trunk@origin
  Use `jj branch list` to see details. Use `jj git pull` to resolve.
The working copy is clean

and finally, jj git pull says:

error: Found argument 'pull' which wasn't expected, or isn't valid in this context

USAGE:
    jj git [OPTIONS] <SUBCOMMAND>

For more information try --help

I'm not sure how I'm supposed to resolve this kind of conflict or why it exists, but at least the command I'm being pointed to doesn't seem to exist.

Specifications

• Platform: linux
• Version:

[zygoloid]

After trying various things that didn't work, I found I could resolve this conflict by deleting the remote and re-adding it.

[martinvonz]

The suggestion to use jj git pull (which is fixed to say jj git fetch by #404) should only happen if the remote branch was updated by two conflicting operations. That can happen if you run e.g. two concurrent jj git fetch commands or if you used jj --at-op=<some old operation> git fetch or jj undo <some old operation>. If you didn't do any of those, it seems like a bug.

Regarding the conflicted trunk branch, I would expect the conflict to happen iff the trunk branch on the two remotes pointed to different commits and one was not ancestor of the other. The idea is that you'll then have to decide where it's supposed to point by running e.g. jj branch set trunk -r trunk@upstream (if you want to use upstream's definition).

[martinvonz]

By the way, if you have time, you can use jj op log to see the operations you've performed on the repo and then use jj --at-op <some operation ID> st to bisect which operation introduced the conflicted branch state. It'll also be clear from jj op log if there were any concurrent operations (either actually concurrent or just effectively concurrent if you ran a mutating command such as jj git fetch with --at-op).

[zygoloid]

I didn't do any of the things you listed as potentially causing this problem, so it sounds like it's a bug. It just happened to me again; the command that introduced the conflicting state was jj git push, and there were no concurrent commands running.

I can reproduce this:

1. Removing and re-adding the remote clears out the conflict state.
2. Running jj git fetch says nothing changed, no conflict reported by jj st.
3. Running jj git push results in jj st reporting a conflict, despite nothing changing.

[zygoloid]

One thing that might be relevant: for a while I had two different remotes configured with the same URL (because I wanted a name other than origin for my default remote), and I was only fetching / pushing one of the two. The other one was not mentioned at all in the conflict, but perhaps its mere existence was causing problems?

[martinvonz]

I still can't figure out what's going on :( Let's look at this bit from your first report:

trunk: hashA New commit from upstream
  @origin (conflicted):
  - hashC Old commit from origin and upstream
  + hashA New commit from upstream

That kind of conflict with one negative and one positive term should mean that the branch was moved from hashC to hashA on the remote and was deleted on same remote. As I said, that should only happen if you ran two jj git push or jj git fetch commands in parallel, so something weird is going on here. I wonder if this bug is related to your #413. As with that bug, there may be some useful hints in jj branch list, if you could share the output of that before and after the bad jj git push.

[martinvonz]

I haven't been able to reproduce this using the steps in #412 (comment) above, but I'm quite confident it's a version of the same problem as in #463. See explanation in #463 (comment). I'll close this bug and use that one for tracking the fix.