Letting agents help with conflicts
Sometimes rebasing is boring.
Sometimes it conflicts.
When that happens, I try not to turn conflict resolution into a heroic manual exercise. I make the state explicit, then I ask an agent to help.
The normal start is:
jj git fetch
jj rebase -o main
If I am maintaining a stack of temporary PR branches, I use the bookmark revset:
jj git fetch
jj rebase -b 'bookmarks("push-*")' -o main
With my config, that is:
jj git fetch
jj rs
If there is a conflict, I first inspect the state:
jj log -r 'conflicts()'
Conflicts may not be at @
After rebasing a stack, the conflict can live in an older commit while my working-copy change looks clean. I do not assume jj status is enough; I ask jj which revisions have conflicts.
Then I list the conflicted files for the specific revision:
jj resolve --list -r <conflicted-change>
If the conflicted change is already @, I edit the files directly.
Most of the time in a stack, I create a working change on top of the conflicted change:
jj new <conflicted-change>
Then I give that state to the agent and ask for a narrow fix.
What I ask the agent for
I do not ask it to redesign the change. I ask it to resolve the conflicted files while preserving the intent of my branch and the new shape of main.
After the agent edits files, I review the result:
jj status
jj diff
If I created a new change on top of the conflicted revision, I squash the resolution back into the conflicted change:
jj squash
jj diff -r <conflicted-change>
If the stack was already pushed as push-* branches, I push everything again:
jj git push -b 'push-*'
With my config:
jj ps
The important habit is not the exact command. The habit is to stop, expose the state, fix the conflict, and review the final diff before pushing.
Conflicts are not failures. They are just places where the graph needs a human decision.