recovering from divergent changes

[vcunat]

The docs say to abandon either of the git hashes. But when I do that, the disambiguated change additionally gets ripped out of the line of change IDs. I wanted to preserve that line and only fix the change ID.

What am I missing? Is this a bug in code, this docs, or did I misunderstand?

[vcunat]

As a workaround I was rebasing that fixed change ID back into the correct place, but man that was really poor UX. (at least deferring of conflict resolution did save me from the worst)

[tim-janik]

The docs say to abandon either of the git hashes. But when I do that, the disambiguated change additionally gets ripped out of the line of change IDs. I wanted to preserve that line and only fix the change ID.

What am I missing? Is this a bug in code, this docs, or did I misunderstand?

The docs assume that in most cases the divergent changes are dups, and so you are best off to abandon them:
https://martinvonz.github.io/jj/latest/FAQ/#how-do-i-deal-with-divergent-changes-after-the-change-id

Using jj duplicate is also an option, this can also duplicate a range of revision if a whole subtree consists of divergent changes.

If you are looking for better UX, I have implemented a jj-fzf vivifydivergent <commitid> command (Alt+V in jj-fzf) that will use new+squash to create a new change_id for a commit. That takes one keypress per divergent commit fixup.

[martinvonz]

How did you end up with the same change ID on two commits? Were/are both commits "public" so you don't want to rewrite either of them? Otherwise you can use jj duplicate and then abandon the old versions.

If you do need to keep both commit IDs unchanged because they're public, then we don't have a way of doing that yet, so you would have basically have to reclone your repo. You could probably do rm .jj/repo/store/extra/heads/*; jj debug reindex instead, but that's obviously not a supported workflow, and it will mean that change IDs change and that your jj evolog will be broken (it will not crash, it will just not know about previous versions of commits). We may need to add a command for replacing a change ID in Git-backed repos.

[tim-janik]

Do you mean even when using a non-Git backend?

As long as divergent change IDs are local, it would be good to give users a simple option to fix this, apart from abandoning.
Now suggested in #5116 as jj describe --new-change-id='', with prefix support users could also opt to keep the first few letters of a divergent change_id.

Since they are likely to embed the change ID in the commit ID (if their commit ID is a content hash), I don't see how we can do that.

I looked into that the last few days, thanks to the pointers provided by you and others I understand the scenario much better now. I really appreciate @arxanas input in the above comment and in the Discord discussion Change ID semantics.

Adding checks to reduce the potential for divergent changes would be helpful, and also the steps described in the above discussion to reconcile divergent changes coming from a forge:

a) Try to treat immutable commits with a fixed change_id as non-divergent - e.g. disambiguate by date or maybe accept only a prefix of the change_id mentioned in the report? Or make local change_ids always longer than ones from forges, etc.

b) Allow users to reconcile two divergent immutable commits with the same change_id, by creating a newer merge commit on top with the same change_id, and give precedence to that commit.

It probably boils down to one very basic decision:

Is a change_id a "label" for a single commit, or for a set of (potentially) multiple commits?

In case of the former, all sorts of workarounds may be needed and the UI grows warts like the current ?? indicators.
In case the latter statement is more appropriate, the docs and some of the handling might need adaptations.

[bendk]

On the contrary. The divergent change is there to help you discover cases like this, so you can decide together with the other person which version of it you want to keep. But it's a good question what we should do in cases where you want to keep both versions of a change. I suppose we don't have much choice but to let the change be permanently divergent in that case.

Maybe this could be treated differently in the UI? Currently, the UI makes me feel like something is wrong and I need to fix it before continuing my work. Maybe instead it could communicate something a more mellow and less urgent -- "you and your co-developer have diverged, maybe you'll way to reconcile this at some point". Instead of a red marker and the word "conflict", it could a yellow marker with the word "divergent".

[martinvonz]

Instead of a red marker and the word "conflict", it could a yellow marker with the word "divergent".

We currently add a "??" suffix to the change id and color it red. I'm okay with making it yellow instead, though we may a different color for the email that's just next to it in that case. We use the word "conflict" and red color for conflicts in file content. We could make those yellow too.

[jennings]

We currently add a "??" suffix to the change id and color it red. I'm okay with making it yellow instead, though we may a different color for the email that's just next to it in that case. We use the word "conflict" and red color for conflicts in file content. We could make those yellow too.

<bikeshed> I think diverging changes being yellow is a good idea because it's more like a warning than a hard error. You might not need to fix divergence, especially if it's in two changes that are now immutable.

But, conflicts are something you probably need to fix at some point, so I think those make sense staying red.

[arxanas]

It probably boils down to one very basic decision:

Is a change_id a "label" for a single commit, or for a set of (potentially) multiple commits?

In case of the former, all sorts of workarounds may be needed and the UI grows warts like the current ?? indicators. In case the latter statement is more appropriate, the docs and some of the handling might need adaptations.

I believe there's a fully-expected (?) workflow where you apply/cherry-pick a change into some other branch, and you later may or may not merge them. In that case, the "change" really lives in multiple commits, and therefore must be a label for multiple commits.

• In that situation, you don't even want to warn.
• I expect that all such development branches would be treated as "immutable", though.
  • Note that there may be points in time where the same change lives in multiple branches without any common descendant/head, depending on whether multiple branches were merged, but I think that's still a non-warning condition.
• Therefore: I think the warning criterion is when multiple commits have the same change ID, and at least one such commit is mutable.
  • Including when two commits are mutable but both have the same change ID.
  • Including when one commit is mutable and one is immutable, but both have the same change ID.
  • Not including when two immutable commits have the same change ID.
  • The good news is that we don't have to check every change ID for uniqueness, which I believe wouldn't scale to Google levels.
    • To detect this scenario, we can hopefully do it in $O(\left|\text{mutable-commits}\right|)$ and not $O(\left|\text{all-commits}\right|)$.
    • Assuming that it's $O(1)$ to check what commits a change ID resolves to globally (which... it might not be in practice).

In rebase-oriented workflows, when you rebase a branch containing a certain change onto another branch containing a commit with the same change ID, I suspect the desired behavior is different:

• You generally want to drop the change altogether, or perhaps create a new change to represent the application of the old version of the same change.
• Nothing immediately comes to mind for a workflow where you would want both commits to share the same change ID, but I could be convinced otherwise.
• Alternatively, I suppose you could do something where, whenever you would rebase a change onto a destination which contains another commit with the same change ID, you try to create a merge commit for the two commits comprising change, which in some sense would track/justify the operation of "applying additional stuff" to the same change. I don't know if any real-world workflow would benefit from that, though.