conflicted interdiff has counter-intuitive output

[Zoybean]

In an interdiff between 2 commits that do not resolve any conflicts, and that do not agree on the initial state of a modified file, the output states "conflict resolved in <file>". This is not necessarily problematic, but it was surprising, and I think it could probably be improved.

Here's a fairly minimal example of what I mean:

1. jj git init
2. echo "foo" > foo
3. jj branch create foo
4. jj new
5. echo "bar" > foo
6. jj new
7. echo "baz" > foo
8. jj branch create baz
9. jj new foo
10. echo "qux" > foo
11. jj branch create qux
12. jj interdiff --from baz --to qux

output is:

Resolved conflict in foo:
   1     : <<<<<<< Conflict 1 of 1
   2     : %%%%%%% Changes from base to side #1
   3     : -bar
   4     : +foo
   5     : +++++++ Contents of side #2
   6     : baz
   7    1: >>>>>>> Conflict 1 of 1 endsqux

I don't really know what the output should say, which is why I haven't made this a proper bug report or feature request. It just seems that the current output is misleading, as there is no actual resolved conflict in an interdiff. I thought it was a bug, initially, until I managed to find a minimal example and realised it was just an ordinary conflict in an interdiff.

[ilyagr]

Interesting point. Thanks for raising it!

I'm a bit flummoxed -- I see how this can be confusing, but I'm also having a hard time seeing how this could be redesigned to work better. I find interdiff a bit confusing in general, and your example is an excellent illustration for that, but I don't have a better idea for its use-case.

---

You may have already figured this out, but to clarify what's going on: jj interdiff --from baz --to qux is designed give similar output to if you rebased and then did the diff. So, it's similar to jj rebase -r baz --to qux-; jj diff --from baz --to qux, except that interdiff does this without actually moving the commit.

In your example, the rebase would have created a conflict. Since qux doesn't contain a conflict, jj diff says that the conflict is resolved (which is what it always says if there is a conflict on the left side but not on the right side).

So, everything is "working as designed" AFAICT, and it's the design we'd have to adjust to help with this.

[martinvonz]

The baz diff is bar=>baz while the qux diff is foo=>qux. So the interdiff should somehow tell you that you're undoing the bar=>baz diff and doing the foo=>qux diff. Maybe #4062 would help. Instead of this:

Resolved conflict in foo:
   1     : <<<<<<< Conflict 1 of 1
   2     : %%%%%%% Changes from base to side #1
   3     : -bar
   4     : +foo
   5     : +++++++ Contents of side #2
   6     : baz
   7    1: >>>>>>> Conflict 1 of 1 endsqux

You would then get something like this:

Resolved conflict in foo:
  Part 1:
   1    1: fooqux # where "foo" is red and "qux" is green
  Part 2:
   1    1: bazbar # where "baz" is red and "bar" is green

Instead of just "Part 2" there, we could say something like "Discarded diff", but that might make it sound like the diff we display is the forward diff (i.e. bar=>baz), which it is not, and I don't think we should make it a forward diff either.

[martinvonz]

Oh! Except that it seems to indicate that the hypothetical conflict-in-conflict I mentioned in an earlier comment, wouldn't really be a significant edge case at all, as it would still just be adding and removing ordinary diffs to/from a conflict, rather than some kind of complicated meta-conflict.

Exactly! I actually stored higher-order conflicts as nested 2-sided conflicts in a very old version of jj (when it was still stored in a Mercurial repo, before I open-sourced it). I was happy when I realized it could be replaced by a list-based form because it made operations on conflicts a lot easier to reason about.

[martinvonz]

I think it might be best to try to keep the diffs in a conflict together as much as possible. So if we have a diff from A+(B-C) to D+(E-F), I think it might be best to display that as diffs D-A, E-F, and C-B (negated B-C since it's on the left side). Maybe that's what you've already implemented, @ilyagr? I haven't checked your PR yet. If it's not, did you consider it and reject it?

[ilyagr]

It looks like both changing a side and changing a base could be expressed as removing one diff and adding another. That would reduce conflicts and resolutions (and maybe all changes?) to combinations of 2 basic operations:
That would reduce conflicts and resolutions (and maybe all changes?) to combinations of 2 basic operations:

I just realized that, up to conflict theory equivalence, "changed a side X -> Y" is equivalent to adding a diff with base X and side Y. If you then cancel out equivalent terms on top and bottom of the conflict, you get the same result as if you changed the side from X to Y.

I'm not sure whether this would lead to a clear way of presenting the situation to a user, but maybe? I'm not sure how to communicate the cancelling out of the terms.

---

For any Z, you could also present it as adding a diff Y-Z and a diff Z-X. For presentation, the empty Z could be OK to use, but generally the fact that we have to invent a Z that doesn't matter to split operations in this way doesn't seem that encouraging to me (even though it's a good point that this is possible).

[ilyagr]

I think it might be best to try to keep the diffs in a conflict together as much as possible. So if we have a diff from A+(B-C) to D+(E-F), I think it might be best to display that as diffs D-A, E-F, and C-B (negated B-C since it's on the left side). Maybe that's what you've already implemented, @ilyagr? I haven't checked your PR yet. If it's not, did you consider it and reject it?

The current implementation tries to optimize everything to minimize diff size (though the algorithms it currently uses is greedy and therefore not great).

I think that's generally better, especially for blame and absorb applications, but I have not re-thought this over in light of your comment and my previous comment, so remind me to mull it over again if I forget.

[ilyagr]

I think it might be best to try to keep the diffs in a conflict together as much as possible. So if we have a diff from A+(B-C) to D+(E-F), I think it might be best to display that as diffs D-A, E-F, and C-B (negated B-C since it's on the left side). Maybe that's what you've already implemented, @ilyagr? I haven't checked your PR yet. If it's not, did you consider it and reject it?

(Quoting myself from Discord update: decided to de-duplicate the post to just here)

Here are two equivalent presentations of the situation if the conflict

<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
-bar
+foo
+++++++ Contents of side #2
baz
>>>>>>> Conflict 1 of 1 ends

was resolved to foo.

Version 1

Resolved conflict in foo:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< BEGIN CONFLICT DIFF
=========== Unchanged Side
foo
=========== Removed a Diff (-1 Base and -1 Side)
-| -bar
-| +baz
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   END CONFLICT DIFF

and (equivalently)

Version 2

Resolved conflict in foo:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< BEGIN CONFLICT DIFF
=========== Removed a Diff (-1 Base and -1 Side)
-| -bar
-| +foo
=========== Changed one of the Sides
-baz
+foo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>   END CONFLICT DIFF

---

I'm not sure whether it would be good if we chose the latter presentation because it was closer to how jj materialized the original conflict. Or maybe? (Of course, we should also imagine a case where foo is much more complicated. Another case is where foo is more complicated and was changed just a tiny bit)