Conflicts should not include lines common to all sides

[9999years]

Jujutsu will show me conflicts where most of the lines are identical on both sides:

<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
+a
+c
+d
+++++++ Contents of side #2
a
b
c
d
>>>>>>> Conflict 1 of 1 ends

Instead, it should show me a conflict like this, making it clear that both sides agree on 3/4 of the added lines:

a
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
+b
>>>>>>> Conflict 1 of 1 ends
c
d

In the trivial case it's fairly easy to resolve these conflicts, but I've gotten into situations where the 'changes' show a snapshot of the entire file on each side. When that happens, I have to copy each side into a separate file and diff them manually.

A script to reproduce this conflict

cd $(mktemp -d)
jj git init --colocate
echo "a
b
c
d" > foo.txt
jj bookmark create change1 --revision=@

jj new 'root()'
echo "a
c
d" > foo.txt
jj bookmark create change2 --revision=@

jj duplicate change1 --destination=change2
jj edit @+
cat foo.txt

Related:

• FR: conflict-marker-style base-with-diffs #6021

[9999years]

NB: In Git-land, I have a Vim plugin that moves common lines outside of the diff markers to help with resolving conflicts: https://github.com/mkotha/conflict3/

[martinvonz]

The conflict actually has 3 sides (all conflicts have an odd number of sides). It's easier to see using Git's diff3 style (what we call the git style), which would be something like this:

<<<<<<< Conflict 1 of 1
Changes from base to side #1
a
c
d
======= base (no terminating newline)
+++++++ Contents of side #2
a
b
c
d
>>>>>>> Conflict 1 of 1 ends

So one of the sides is an empty string, which of course doesn't have anything in common with either of the other sides. That's the reason we don't move those parts out of the conflict markers. If we did, we would get a different conflict back when we try to parse the conflict marker back (which we do when we snapshot the working copy).

[9999years]

Ah. Is there anything we can do to help users out here? Presumably the "base" is the merge-base of the commits (i.e. the root commit).

[martinvonz]

Yes, the base is the merge base if you did jj new X Y, or X's parent if you did jj rebase -r X -d Y.

I don't know how to make it clearer. Perhaps we could add some annotation in the same style as "(no terminating newline)", such as "(base was missing)".

[scott2000]

I don't know how to make it clearer. Perhaps we could add some annotation in the same style as "(no terminating newline)", such as "(base was missing)".

Maybe we could automatically switch to "snapshot" style whenever the base is empty (or for many-sided conflicts, when every base is empty)? Something like this:

<<<<<<< Conflict 1 of 1
+++++++ Contents of side #1
a
c
d
------- Contents of base (empty)
+++++++ Contents of side #2
a
b
c
d
>>>>>>> Conflict 1 of 1 ends

Adding special cases might make conflicts harder to understand though.

[9999years]

Perhaps I should build some (external) tooling that "minimizes" the conflicts in the way I'd like automatically, which is not subject to the constraints mentioned above.

That's the reason we don't move those parts out of the conflict markers. If we did, we would get a different conflict back when we try to parse the conflict marker back (which we do when we snapshot the working copy).

@martinvonz Just to make sure I understand, you're saying that if we moved those parts out of the conflict markers, we would lose the knowledge of what the changes on each side actually were, relative to the base? Could you explain why that's a destructive operation? I would have thought that the information about the conflicts can be derived from the parents, although I know that sort of nonlocal computation can lead to slowdowns like in #5411.

Thanks again for the help and for jj :)

[martinvonz]

It's destructive because we don't consider the parents when snapshot, we only consider the previous snapshot. I think there was some open PR about keeping some additional information between snapshots, however, so maybe it's not that conceptually different to store information about conflicts. I would really like to minimize the state we store there, however. It reduces the risk for bugs if there's no hidden state that affects how we produce a commit from the files in the working copy.

[9999years]

That makes a lot of sense, thanks for the clarification!