Possible bug: abandoning conflicted changes no longer resolves bookmark conflicts

[BatmanAoD]

At least as of v0.32 (but possibly also before), abandoning all but one change-ID from a conflicted commit does not automatically resolve the conflict for any bookmarks attached to that commit. jj bookmark list shows:

branch-name (conflicted):
  - <sha> hidden ...
  - <sha> ...

It seems weird that a "hidden" change would cause a bookmark conflict in the first place, but it seems even weirder that the abandon operation that actually hides the operation leaves the bookmark in a conflicted state.

This behavior would at least seem consistent if abandon didn't operate on bookmarks at all, but it seems inconsistent with the bookmark-deletion behavior¹.

Footnotes

1. I don't want to argue about this behavior here, but just so this discussion isn't taken as tacit approval of the bookmark-deletion behavior, I want to say explicitly that I'm still not a fan. ↩

[yuja]

It's technically correct that jj abandon doesn't (always) resolve conflicted bookmarks because there are still conflicts between old_target -> new_target1 and old_target -> (absent).

initial state:
  old_target
on conflict:
  old_target -> [new_target1, new_target2]
on `jj abandon new_target2`:
  { old_target -> [new_target1, new_target2] } + { new_target2 -> (absent) }
  = old_target -> [new_target1, (absent)]

I don't have a good model to make jj abandon automatically resolve conflicts.

[BatmanAoD]

How is that useful or "correct", though? Is old_target -> absent supposed to indicate that the expected alternative to old_target -> new_target1 is to delete the bookmark?

[martinvonz]

Yes, exactly. It's similar to the kind of modify/delete conflict you get for files when one side modifies the file and the other side deletes the file.

[martinvonz]

The behavior changed in 0.26 when we made jj abandon also delete any bookmarks pointing to the target (https://github.com/jj-vcs/jj/releases/tag/v0.26.0). Before that release, it was probably at least more common that jj abandon would resolve a conflict. It would have happened if new_target2 was a descendant of old_target in Yuya's example.

[BatmanAoD]

What do you think of making it auto-resolve if there is exactly one non-hidden target for the bookmark after the operation completes?

[martinvonz]

Do you mean generally when one side has deleted a bookmark, e.g. by jj abandon or more directly by jj bookmark delete? Or do you mean some special handling in jj abandon? I don't really like either of those. I'm afraid I don't have a proposal I like better either.

[BatmanAoD]

...one side has deleted a bookmark

I'm not talking about bookmark deletions prior to the conflict being created, or about preventing a conflict from occurring in the first place. I'm saying that, once a conflict exists, any operation that hides all but one change should disambiguate the bookmark's state, resolving the conflict. I'm assuming that jj bookmark delete already does resolve the conflict (by deleting the bookmark), so as far as I can tell, this would make the behavior of jj abandon more consistent with other operations.

[BatmanAoD]

I've verified that abandoning all target changes, or deleting the bookmark, both resolve the conflict. So the only change I'm suggesting is that hiding all-but-one should also resolve the conflict. Maybe that would be considered "special handling" in abandon, but it would also apply to other operations that can hide/abandon commits, such as squash, and I wouldn't expect the implementation to be in the actual abandon command logic.