Jujutsu treats conflicts as first-class objects. This guide explains how conflicts work and how to resolve them.

What Are Conflicts?

In Jujutsu, a conflict is a state a change can be in — not an error to immediately fix.

# Create a conflict intentionally
jj rebase -d conflicting-branch

# The change exists, just marked as conflicted
jj log
# (conflict) mnxpqkpv  main
#   My change description

Why This Matters

Git Approach	Jujutsu Approach
Conflict blocks operation	Conflict is a valid state
Must resolve immediately	Can resolve asynchronously
No record of conflict	Conflict stored in history
Binary: resolved/unresolved	Graduated: can annotate

Types of Conflicts

Content Conflicts

Two changes modify the same file region:

file.txt
<<<<<<< Side A
function old() { return 1; }
=======
function new() { return 2; }
>>>>>>> Side B

File Conflicts

• One side modifies, other deletes
• Both sides add file with different content
• Rename conflicts

Complex Conflicts

Multiple files, multiple regions — all tracked together.

Working with Conflicts

Detecting Conflicts

# List all conflicts
jj conflicts

# In log
jj log
# (conflict) indicates conflicted changes

# Show conflict details
jj show conflicted-change-id

Resolving Conflicts

Interactive Resolution

# Start resolution
jj resolve

# For each conflict, choose:
# - Accept A (ours)
# - Accept B (theirs)
# - Merge (edit the result)

Manual Resolution

Edit conflict markers directly:

# Edit files
vim file-with-conflict.txt

# Remove conflict markers, keep desired content

# Mark as resolved
jj resolve --list  # See remaining conflicts

Using Tools

Configure merge tool in ~/.jjconfig.toml:

[ui]
merge-editor = "vscode"
# or "vimdiff", "meld", "idea", etc.

Then:

jj resolve --tool vscode

Abandoning Resolution

# Undo the rebase that caused conflict
jj undo

# Or rebase elsewhere
jj rebase -d different-parent

Conflict Inbox (Kizuna UI)

Kizuna provides a dedicated UI for managing conflicts:

Viewing Conflicts

1. Navigate to Conflicts in repository sidebar
2. See list of all conflicted changes
3. Click for detailed view

Conflict Details

For each conflict:

• Both changes shown side-by-side
• Diff highlighting conflict regions
• Agent annotations (if applicable)
• Suggested resolutions

Resolution Workflow

1. Assign: Route to human or agent resolver
2. Review: Examine both sides
3. Resolve: Choose or create merged version
4. Verify: CI runs on resolved change

Agent-Assisted Resolution

Confidence Annotations

Agents can annotate conflicts with reasoning:

Conflict in auth.js
├── Side A (our change): Add OAuth login
├── Side B (their change): Add SAML login
└── Agent analysis: These are complementary — combine both

Delegation

Escalate to specialist agents:

# Via A2A message
{
  "type": "conflict_arbitration",
  "change_id": "abc123",
  "specialty": "authentication",
  "both_sides": [...]
}

Best Practices

Prevention

1. Pull frequently — Smaller sync windows
2. Communicate — Coordinate with team
3. Small changes — Easier to merge
4. Feature flags — Avoid long-lived branches

Resolution

1. Understand both sides — Don't just pick yours
2. Test the result — Verify merged code works
3. Commit resolution — Explain the merge
4. Learn — Why did this conflict occur?

Team Workflow

1. Conflict inbox review — Daily triage
2. Assign specialists — Domain experts resolve
3. Document patterns — Common resolutions
4. Automate where possible — Detectable patterns

API Access

List Conflicts

curl /api/v1/repos/org/repo/conflicts

Get Conflict Details

curl /api/v1/repos/org/repo/conflicts/abc123

Resolve via API

curl -X POST /api/v1/repos/org/repo/conflicts/abc123/resolve \
  -d '{"resolution": "side_a", "reason": "Side A has better error handling"}'

Summary

Jujutsu's first-class conflicts enable:

• Async resolution — No immediate pressure
• Structured tracking — Conflicts are data
• Agent involvement — Automated analysis
• Complete audit — Resolution history preserved

This transforms conflicts from interruptions into manageable workflow items.