jj leaves stale commit IDs in conflict markers

[Christoph-D]

Description

jj doesn't update commit IDs in conflict markers in the working copy when rewriting a change with conflicts.

Steps to Reproduce the Problem

$ cat repro.sh
#!/bin/bash

set -e

jj git init test-repo
cd test-repo

jj commit -m 'initial commit'
echo 'content: A' > file.txt
jj commit -m 'write A'
jj new '@--'
echo 'content: B' > file.txt
jj commit -m 'write B'

echo -e '\n*** Create conflict'

jj new zzzzzzzz++

echo -e '\n*** File content:'
cat file.txt

echo -e '\n*** Log:'
jj log

echo -e '\n*** Abandon base change'
jj abandon zzzzzzzz+

echo -e '\n*** File content:'
cat file.txt

echo -e '\n*** Log:'
jj log

Then:

$ chmod +x repro.sh && ./repro.sh 
Initialized repo in "test-repo"
Working copy  (@) now at: lqznsxxp c0fd4859 (empty) (no description set)
Parent commit (@-)      : spkoylnt 2d18f72c (empty) initial commit
Working copy  (@) now at: kzuuukyz d25c2f0d (empty) (no description set)
Parent commit (@-)      : lqznsxxp d87f2449 write A
Working copy  (@) now at: lprtmmuz 7c94ecd7 (empty) (no description set)
Parent commit (@-)      : spkoylnt 2d18f72c (empty) initial commit
Added 0 files, modified 0 files, removed 1 files
Working copy  (@) now at: swspvyoz 5ccc567f (empty) (no description set)
Parent commit (@-)      : lprtmmuz 122d05bd write B

*** Create conflict
Working copy  (@) now at: xlmmplyl 2f8f66e3 (conflict) (empty) (no description set)
Parent commit (@-)      : lprtmmuz 122d05bd write B
Parent commit (@-)      : lqznsxxp d87f2449 write A
Added 0 files, modified 1 files, removed 0 files
Warning: There are unresolved conflicts at these paths:
file.txt    2-sided conflict

*** File content:
<<<<<<< conflict 1 of 1
%%%%%%% diff from: spkoylnt 2d18f72c "initial commit"
\\\\\\\        to: lprtmmuz 122d05bd "write B"
+content: B
+++++++ lqznsxxp d87f2449 "write A"
content: A
>>>>>>> conflict 1 of 1 ends

*** Log:
@    xlmmplyl code@example.com 2026-08-21 23:01:29 2f8f66e3 (conflict)
├─╮  (empty) (no description set)
│ ○  lqznsxxp code@example.com 2026-08-21 23:01:29 d87f2449
│ │  write A
○ │  lprtmmuz code@example.com 2026-08-21 23:01:29 122d05bd
├─╯  write B
○  spkoylnt code@example.com 2026-08-21 23:01:29 2d18f72c
│  (empty) initial commit
◆  zzzzzzzz root() 00000000

*** Abandon base change
Abandoned 1 commits:
  spkoylnt 2d18f72c (empty) initial commit
Rebased 3 descendant commits onto parents of abandoned commits.
Working copy  (@) now at: xlmmplyl 164d3bd4 (conflict) (empty) (no description set)
Parent commit (@-)      : lprtmmuz bc44bec2 write B
Parent commit (@-)      : lqznsxxp a0cea1e4 write A
Warning: There are unresolved conflicts at these paths:
file.txt    2-sided conflict

*** File content:
<<<<<<< conflict 1 of 1
%%%%%%% diff from: spkoylnt 2d18f72c "initial commit"
\\\\\\\        to: lprtmmuz 122d05bd "write B"
+content: B
+++++++ lqznsxxp d87f2449 "write A"
content: A
>>>>>>> conflict 1 of 1 ends

*** Log:
@    xlmmplyl code@example.com 2026-08-21 23:01:29 164d3bd4 (conflict)
├─╮  (empty) (no description set)
│ ○  lqznsxxp code@example.com 2026-08-21 23:01:29 a0cea1e4
│ │  write A
○ │  lprtmmuz code@example.com 2026-08-21 23:01:29 bc44bec2
├─╯  write B
◆  zzzzzzzz root() 00000000

Expected Behavior

jj should update the conflict markers to point to the rewritten commit IDs.

Actual Behavior

The conflict markers in the working copy still refer to the old superseded commit IDs.

For example

+++++++ lqznsxxp d87f2449 "write A"`

should be

+++++++ lqznsxxp a0cea1e4 "write A"`

to match the commit ID of the rewritten change.

Specifications

• Platform: Ubuntu 26.04
• Version: 0.44

[josephlou5]

In my mind, the commit IDs are there so you can go query the actual commit in case you want more context about the changes (or want to see that diff in isolation). Even if the change ID is the same, a different commit ID can have entirely different content in the conflicted file. It sounds like it would be somewhat complicated for jj to figure out even if the commit ID can be reasonably updated in conflict markers (if nothing else in the file changed, I guess maybe it's safe?). Also since the conflict is materialized in the file itself, it sounds potentially expensive for jj to scan through all your files looking for conflict markers to update.

Just my 2 cents though.

[Christoph-D]

Even if the change ID is the same, a different commit ID can have entirely different content in the conflicted file.

I see. If file content changes in an ancestor change of a conflicted change, jj creates a 3-sided conflict instead of rewriting the conflicts.

This means if jj were to update the conflict markers, it could only do it safely if the file wasn't modified elsewhere. Otherwise the conflict marker update itself would create a 3-sided conflict, which would be bad UX because it'd be a pointless conflict.

The reason I'm looking for the updated commit IDs is that I'm working on a jj tool where I'd like to consistently show <short_change_id>/<offset> matching jj log because I find it easier to read than <change_id> <commit_id> as long as the offset is kept up-to-date and matches what jj log shows.

The only place where I couldn't find a good way to do this is conflict markers because they go stale and refer to commits no longer shown in the default jj log.

But I agree. Unless I'm missing something, I don't see a good way for jj to update the conflict markers without creating pointless 3-sided conflicts or still leaving stale markers in some cases. Maybe there's a good consistent way but I'm not seeing it.

[josephlou5]

The reason I'm looking for the updated commit IDs is that I'm working on a jj tool where I'd like to consistently show <short_change_id>/<offset> matching jj log because I find it easier to read than <change_id> <commit_id> as long as the offset is kept up-to-date and matches what jj log shows.

When you say "consistently", are you building a view into the conflicted file, such as a TUI or something? Or do you actually want the materialized conflict contents to be updated on disk? (The latter is what I interpreted your original request as.)

My immediate thought to this first question is that you could grab the change ID and commit ID from the conflict markers, then run something like:

change_id='...'
commit_id='...'
jj evolog -G -r="${change_id}" -T "if(stringify(self.commit().commit_id()).starts_with('${commit_id}'), format_short_change_id_with_change_offset(self.commit()))"

This should give you back the change_id/offset format that you want for the commit ID in question, which you could then use in your dynamic view (assuming that's what you have).

Alternatively, since you know the change ID, you could get all historical change offsets with:

jj evolog -G -r="${change_id}" -T 'self.commit().commit_id() ++ ":" ++ format_short_change_id_with_change_offset(self.commit()) ++ "\n"'

And then use this mapping as a "cache" to avoid invoking jj multiple times.

Anyway, went off on a bit of a tangent, but in case it's useful to you.

[Christoph-D]

When you say "consistently", are you building a view into the conflicted file, such as a TUI or something? Or do you actually want the materialized conflict contents to be updated on disk? (The latter is what I interpreted your original request as.)

The latter, so that a merge editor (in VS Code) can label the sides in a way that the user can look up the commits in the default jj log output. The stale commit IDs make this difficult because the superseded commits are no longer in jj log.

Translating into change_id/offset is unfortunately not a solution because it has the same issue: The change_id/offset of a superseded commit will not be visible in the default jj log.

The commit might even have been garbage-collected, making it impossible to look up. I confirmed that commits referenced only in conflict markers are garbage collected.

For now I went with a simple heuristic to avoid additional jj calls, preferring change ID over precision:

1. Look up (change_id_prefix, commit_id_prefix) in the jj log details which I already cache. If found -> use the short change ID/offset from there
2. Look up change_id_prefix in the cached jj log, ignoring commit ID. If found -> use the short change ID and print ? as the offset; also show the commit ID as disambiguation
3. If still not found, print what's in the conflict markers

Still not perfect because 8 letter change IDs have a chance to collide, the ? offset is not great, and VS Code doesn't support per-block labels, only per-side labels, but I prefer it over showing the long 8 letter labels from the conflict markers. 8 letters are somehow both too long (to read) and too short (to be unique).

For my purposes, not updating the conflict is markers is OK. It would be nicer if the markers were up-to-date but it's only a fairly small UI issue.

I found this jj behavior quite surprising. But the more I think about this the harder it seems to update the markers consistently without causing unintended changes. If you think it's complicated to implement this, it's probably not worth it until a stronger use case appears.

[josephlou5]

When you say "consistently", are you building a view into the conflicted file, such as a TUI or something? Or do you actually want the materialized conflict contents to be updated on disk? (The latter is what I interpreted your original request as.)

The latter, so that a merge editor (in VS Code) can label the sides in a way that the user can look up the commits in the default jj log output. The stale commit IDs make this difficult because the superseded commits are no longer in jj log.

FWIW, this doesn't seem possible in general anyway. I'm also a little curious what you mean by "default jj log output" -- is it specifically builtin_log() that you're constrained to here? That seems like it definitely wouldn't work. Imagine a situation where you're working on main, but then main gets advanced on the remote, so you jj git fetch && jj rebase -r 'mutable()' -o main, but then you get conflicts. The old parent (which is now somewhere in ancestors(parents(main))) won't be visible in builtin_log(), but will be listed in the conflict markers as the old parent of the rebased commit. My customized revsets.log also would not show the old parent. But perhaps I'm missing context on what you're doing specifically.

I confirmed that commits referenced only in conflict markers are garbage collected.

Are you explicitly running garbage collection? I don't think jj truly deletes old commits unless you ask it to (but I may be wrong). But also, if you're trying to make this work in general in any repo, then yeah you can't assume that an old commit actually exists.

I also just realized that if you know the commit ID then you can just do jj log -G -r="${commit_id}" -T 'format_short_change_id_and_change_offset(self)' and immediately get the most up-to-date change offset format. Not sure why I was complicating it so much earlier :p

But the more I think about this the harder it seems to update the markers consistently without causing unintended changes. If you think it's complicated to implement this, it's probably not worth it until a stronger use case appears.

Agreed, it seems difficult :') FWIW I'm just a rando (not a maintainer, and not familiar with conflict resolution logic), so I wouldn't really know how hard this is to actually implement.

[Christoph-D]

FWIW, this doesn't seem possible in general anyway.

Maybe. I don't know how well jj's internal model of conflicts can represent such updates.

I'm also a little curious what you mean by "default jj log output" -- is it specifically builtin_log() that you're constrained to here?

My jj tool renders a jj graph by calling jj log with a custom template and (mostly) a default revset. Commits outside this revset are unreachable by the user unless they fall back to the jj CLI. This is why I'd like to only reference visible commits whenever possible.

In my example repo in the first comment, it looks plausible to me for jj to update the conflict markers; jj already rewrites change xlmmplyl and materializes any changes except updating conflict markers. But I'm sure there are a lot of corner cases to consider.

Are you explicitly running garbage collection?

I'm not. What I meant with "commits referenced only in conflict markers are eligible for garbage collection" was to show another case where jj doesn't treat commit references in conflict markers as real references, and instead seems to forget they exist. I thought this might be related because updating conflict markers means jj needs to keep track of or rediscover old conflict markers.

[scott2000]

Does this still happen if the base commit isn't empty? We do update conflict labels when rebasing commits in many cases, so my guess would be that the labels would be updated as expected if the base commit wasn't empty.

For the case in the example you gave, there's an optimization where if the parent trees didn't change, we don't update the tree while rebasing:

jj/lib/src/rewrite.rs

Lines 381 to 389 in 0fa35ae

	let (was_empty, new_tree) = if new_parent_trees == old_parent_trees {
	(
	// Optimization: was_empty is only used for newly empty, but when the
	// parents haven't changed it can't be newly empty.
	true,
	// Optimization: Skip merging.
	self.old_commit.tree(),
	)
	} else {

[Christoph-D]

Interesting. It doesn't happen if the base commit is not empty. In that case, jj updates the conflict markers.

I tested this by putting an unrelated file into the base commit. Abandoning the base commit then updates the commit IDs in the conflict markers even though the base commit only contains an unrelated file.

Then it looks like a real bug to me: The optimization misses conflict markers, which can change without visible changes in the tree because they reference commit IDs.

[scott2000]

I'm not sure if I would consider it a bug since we don't guarantee that conflict labels refer to visible commits (and for conflicts resulting from rebasing or squashing, usually at least one of the conflict labels will refer to a hidden commit). The old conflict labels are still technically accurate, but they just happen to refer to hidden commits. But it definitely is confusing that the behavior is different depending on whether the optimization, so maybe we should fix it anyway.

Also to add some more context on how conflict labels work, when there's a conflicted commit, it's represented as a merge of some number of trees. Each tree has a conflict label associated with it, which is just stored as a plain string (the change ID and commit ID are part of that string, they're not stored in any special way). Since the conflict labels are just strings, it would be difficult to directly update the change ID and commit ID. When rebasing, what's actually happening is that a brand new conflict label string is created, and it replaces the old one after the conflict is simplified.