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]

I suppose we don't have much choice but to let the change be permanently divergent in that case.

Please add a way to force a new change_id for such cases. Otherwise this situation leads to another DOS scenario, because a number of jj commands simply refuse to operate on divergent changes.
Using vivifydivergent is also not an option in all cases, it resets the author-date, doesn't work with immutable commits and obviously cannot preserve a commit_id (which may have been publicly exposed).

[martinvonz]

Do you mean even when using a non-Git backend? 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.

[arxanas]

If the change ID is meant to be irrevocably embedded in the commit metadata (and I'm not specifically sure that it should in the general case?), then perhaps jj should adopt one of the following approaches:

• As an invariant, forbid having a commit with a certain change ID be the ancestor of a commit with the same change ID.
  • There's some nice properties that you probably gain when thinking about it from a "patch-set" workflow, where you want to consider a given ref to logically be a set of all patches with the change IDs in that ref's ancestry.
  • From the same "patch-set" perspective, the desired behavior in at least some cases is to implement rebasing a commit with an already-present change ID by skipping it because it's been applied upstream. That would support cherry-picking workflows where you want to apply the same patch to different branches. (There's probably significant UX considerations.)
  • You could get into an unfortunate situation where a backend either doesn't respect this invariant or mistakenly failed to enforce it, which could cause problems when such a commit graph is ingested into your clone.
• Immutable commits with conflicting change IDs should not be treated as "divergent", as it's no longer possible to rectify the situation, and therefore this situation shouldn't block operations.

There might be a good reason to treat the change ID as logically mutable metadata (perhaps still implemented with an immutable CRDT for synchronization purposes) and design the object model to support that.

[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".