What to do with conflicted remote branches?

[tp-woven]

Not sure how, but I managed to get this situation where my remote main has a conflict:

❯ jj st
Parent commit: c8b0e2c2a96f XXXXX
Working copy : 2e33ef7ab066 (no description set)
These remote branches have conflicts:
  main@origin
  Use `jj branches` to see details. Use `jj git pull` to resolve.
The working copy is clean
❯ jj branch list
main: c72ee8c8e807 Merge pull request #1189 from XXXXX
  @origin (conflicted):
  - eac2ea223f23 Merge pull request #1187 from XXXXX
  + c72ee8c8e807 Merge pull request #1189 from XXXXX

I think I was in main == main@origin == eac2ea223f23, and ran jj git fetch which should have updated both main and main@origin to c72ee8c8e807 (eac2ea223f23 is in c72ee8c8e807's history).

Other than the confusion of why this happened, I am now faced with the question - How do I resolve this? jj co main@origin simply checks out c72ee8c8e807 with a clean working copy and no conflict markers, and jj branch set main@origin -r c72ee8c8e807 doesn't seem to have any effect. Any suggestions other than nuking the repo?

[martinvonz]

That kind of conflict, where you have one removed target and one added target, should indicate that the branch was updated by one operation and moved by another. Do you run any git (not jj git) commands directly in that repo? Can you share the recent output of jj op log (after redacting whatever bits you don't want to share)?

Any suggestions other than nuking the repo?

jj op restore <some recent operation> is usually a better option.

[martinvonz]

Oh, you can use e.g. jj --at-op <operation ID> log to see what the repo looked like at a particular operation.

[tp-woven]

Do you run any git (not jj git) commands directly in that repo?

Hmm, OK, now that you ask it reminded me I was having some other issues earlier and I may have messed it up myself...
This morning I encountered this:

❯ jj git fetch
Error: Cannot export conflicted branch 'main'
❯ jj l
o eac2ea223f23 9258e83d65b1 XXXXX@XXXXX 2022-06-09 17:25:51.000 +09:00 main? main@origin
: Merge pull request #1187 from XXXXX
: o 00be5b134fe3 06105ed84cf0 XXXXX@XXXXX 2022-06-09 09:52:42.000 +09:00 main?   HEAD@git divergent
:/  Merge pull request #1172 from cityos-platform/talp/4d8eea4a12bc4fcab9cb7a672e1a7bcf

At this point I may have panicked (😅), and "resolved" the issue by jj forget main (that caused issues with my "log" alias) and git checkout main. At that point everything seemed to work as usual, until I tried fetching again and encountered the behavior in the first post.

Some relevant op log: (Oldest commands in the end, anything after # is my comment)

...
o 0ef12cae11b4 XXXXX 2022-06-10 13:01:01.116 +09:00 - 2022-06-10 13:01:01.756 +09:00
| fetch from git remote origin
| args: jj git fetch
o 33b80e038eb2 XXXXX 2022-06-10 12:59:07.041 +09:00 - 2022-06-10 12:59:07.060 +09:00
| rebase commit ea03a572feac7eb7be638cbc62c1cc69641a08b8 and descendants
| args: jj rebase -s @ -d main
...
o 8a800f1bd4ee XXXXX 2022-06-10 12:58:00.158 +09:00 - 2022-06-10 12:58:00.195 +09:00
| import git refs
| args: jj l # Showed "main main@origin?" on commit `c72ee8c8e807`
o 29745266c9c6 XXXXX 2022-06-10 12:57:56.377 +09:00 - 2022-06-10 12:57:58.927 +09:00
| fetch from git remote origin
| args: jj git fetch # Fetch again, causing main@origin conflict(?)
...
o 9782aba5005e XXXXX 2022-06-10 08:38:01.694 +09:00 - 2022-06-10 08:38:01.728 +09:00
| import git refs
| args: jj l # After running `git checkout main`, this invocation succeeded
o 3f7c83aab3b2 XXXXX 2022-06-10 08:37:24.530 +09:00 - 2022-06-10 08:37:24.602 +09:00
| import git refs
| args: jj l # Failed because my alias depends on "main"
o b4bf8bf7b149 XXXXX 2022-06-10 08:37:21.679 +09:00 - 2022-06-10 08:37:21.694 +09:00
| forget branch main
| args: jj branch forget main
o b9f677033b81 XXXXX 2022-06-10 08:36:28.039 +09:00 - 2022-06-10 08:36:29.876 +09:00
| fetch from git remote origin
| args: jj git fetch # Initial fetch that failed

jj op restore <some recent operation> is usually a better option.

Thanks! 🙇
I'm not sure I understand what that did exactly (my "newer" commits still seem to be there), but after a few restores and some manual resolution of conflicts, I think my repo is OK now. 😄

[martinvonz]

Let's take a look at the output from this morning:

❯ jj git fetch
Error: Cannot export conflicted branch 'main'
❯ jj l
o eac2ea223f23 9258e83d65b1 XXXXX@XXXXX 2022-06-09 17:25:51.000 +09:00 main? main@origin
: Merge pull request #1187 from XXXXX
: o 00be5b134fe3 06105ed84cf0 XXXXX@XXXXX 2022-06-09 09:52:42.000 +09:00 main?   HEAD@git divergent
:/  Merge pull request #1172 from cityos-platform/talp/4d8eea4a12bc4fcab9cb7a672e1a7bcf

That Error: Cannot export conflicted branch 'main' means that there already was a conflict. That could have been caused by running e.g. git branch -f main 00be5b134fe3, but I suspect that wasn't what actually happened.

The simplest way of resolving the conflict is probably to make main point to main@origin by running jj branch set main -r main@origin.

I'm not sure I understand what that did exactly (my "newer" commits still seem to be there)

jj op restore restores your repository to look like it did a while ago. It's similar to git restore/hg revert, but instead of updating your working copy to an earlier state, it updates the repository to an earlier state. Things in the repository state include: the set of visible commits, the currently checked out commit, branches and tags. So

but after a few restores and some manual resolution of conflicts, I think my repo is OK now. 😄

👍

[tp-woven]

That Error: Cannot export conflicted branch 'main' means that there already was a conflict. That could have been caused by running e.g. git branch -f main 00be5b134fe3, but I suspect that wasn't what actually happened.

Yeah, I don't remember doing anything like that recently... I wonder what it was that caused it, then. 🤔

The simplest way of resolving the conflict is probably to make main point to main@origin by running jj branch set main -r main@origin.

Yeah, I'm not sure why I "forgot" main and then checked it out with git... 😅
But would it have the same results, or does forgetting it and then reimporting it from git create a different state?

jj op restore restores your repository to look like it did a while ago.

But what does that mean for commits that weren't in the repo at that point in time? Are they automatically considered "visible" after a restore?

[martinvonz]

That Error: Cannot export conflicted branch 'main' means that there already was a conflict. That could have been caused by running e.g. git branch -f main 00be5b134fe3, but I suspect that wasn't what actually happened.

Yeah, I don't remember doing anything like that recently... I wonder what it was that caused it, then. 🤔

You should be able to find out by looking at the operation log and bisecting it using e.g. jj --at-op <some operation> branches.

The simplest way of resolving the conflict is probably to make main point to main@origin by running jj branch set main -r main@origin.

Yeah, I'm not sure why I "forgot" main and then checked it out with git... 😅 But would it have the same results, or does forgetting it and then reimporting it from git create a different state?

Forgetting the branch means all records of it (at the current operation) are removed. So that should also be a safe and simple way of resolving the conflict. It must be something else that happened. Let me know if you figure out what it was after running the bisection I described above.

jj op restore restores your repository to look like it did a while ago.

But what does that mean for commits that weren't in the repo at that point in time? Are they automatically considered "visible" after a restore?

Sorry, I meant to explain that bit as well. By "visible", I mean that they show up in jj log -r 'all()' (i.e. are ancestors of jj log -r 'heads()'). When you restore to an older operation, you will not see any newer commits in that output. However, the commits are still available in the storage backend and jj checkout <commit> will be able resolve them (similar to unreferenced commits in git).

[tp-woven]

Thanks for the clarifications, Martin!

Unfortunately, my repo was still messed up so I ended up nuking it. I tried to back it up first before getting a clean clone, but I had a terminal window that showed the wrong path in the prompt and the history there is gone... 😞

In any case, going back to the initial subject of the PR, I think it would be a good idea to document what to do in such cases (remote branches either conflicting or diverging from local ones). I'll try to write something up and send a PR for review.