conflicts: materialize simplified conflicts for each file

[bnjmnt4n]

Closes #2795.

Checklist

If applicable:

• I have updated CHANGELOG.md
• [NA] I have updated the documentation (README.md, docs/, demos/)
• [NA] I have updated the config schema (cli/src/config-schema.json)
• I have added tests to cover my changes

[martinvonz]

Could you also add some tests making sure that a simplified conflict can be edited? I haven't checked carefully, so I'm sorry if there already are tests for that.

[bnjmnt4n]

Updated. While modifying some changes in this PR, I was able to use the built version to run jj resolve, which simplified some conflicts from 3-sided to 2-sided. 😎

[ilyagr]

Thank you for working on this!

This PR doesn't do quite what I thought it would; I was thinking of a much more limited simplification, possibly without needing any sort of deduplicate. I wonder whether I missed something important or whether this should be simplified to do less.

[bnjmnt4n]

Actually, does anybody have an example of a set of tree merges which creates a conflict which can be further simplified on the file level? I'm not sure if I'm doing something wrong but I can't seem to figure out a good example.

[joyously]

Does "conflict simplified on the file level" include all aspects: contents, name, existence, executable bit? Or is this just about contents?

[ilyagr]

Actually, does anybody have an example of a set of tree merges which creates a conflict which can be further simplified on the file level? I'm not sure if I'm doing something wrong but I can't seem to figure out a good example.

Here's the example I had:

ilyagr@conflictbugs

If it doesn't work for you as is, look for one of the parent commits (currently ilyagr@2a3abbe and its parent, named " Make tree-level-conflicts the default in tests" and "make new trees the default in tests
"). You may need one or both of them. (Actually, I'll make a PR out of them in a moment; I'm not sure it's "ready to go" but it might be worth discussing)

The examples you already have might also start working with those commits.

[ilyagr]

Let me know if patching #3746 helps. I don't remember whether it was necessary for demonstrating #3223, #2895, or both.

[bnjmnt4n]

Thanks @ilyagr for the pointer, I didn't realize the code in the tests were using the legacy MergedTrees. Maybe there's a difference between the legacy and new code paths which meant my tests weren't working as expected. I'll take a look and see if there's any differences in behavior.

[bnjmnt4n]

Does "conflict simplified on the file level" include all aspects: contents, name, existence, executable bit? Or is this just about contents?

This PR will only simplify the contents of conflicted files, which have the same path. (This includes deletions.)

[ilyagr]

Actually, does anybody have an example of a set of tree merges which creates a conflict which can be further simplified on the file level?

A more concrete example that would work for integration tests and be more or less representative of the most important case: have a merge of two commits that both modify file1 and do not touch file2. The merge will have a conflict in file1. Have another merge of two commits that both modify file2 and do not touch file1. Then, merge the two merges.

[edmundnoble]

Using this branch, I've noticed that in a merge commit, some changes from parent commits disappeared entirely. Perhaps this is the issue @ilyagr is seeing? The commit is available at https://github.com/kadena-io/chainweb-node/tree/push-lzwyzupppxrz.

[bnjmnt4n]

Actually, does anybody have an example of a set of tree merges which creates a conflict which can be further simplified on the file level?

How about a set of jj commands which cause this to happen directly to commits instead of the internal MergedTrees?

[martinvonz]

Actually, does anybody have an example of a set of tree merges which creates a conflict which can be further simplified on the file level?

How about a set of jj commands which cause this to happen directly to commits instead of the internal MergedTrees?

If I understand correctly what you're asking for, this should work:

jj git init
echo a > file1
echo a > file2
jj new @-
echo a > file1
echo b > file2
jj new @-
echo b > file1
echo c > file2
jj new 'all:visible_heads()'

You should now have a 3-sided conflict file2 and in the root tree. Because we don't do per-file simplification yet, the conflict in file1 would also be 3-sided, but it could be simplified to a 2-sided conflict.

Is that what you were looking for?

[ilyagr]

Martin's suggestion should work fine. My suggestion from #3719 (comment) is a lot more verbose, but I find it in some ways easier to reason about:

jj new -m 'base'
echo base > fileA
echo base > fileB

jj new; jj branch create A1
echo X > fileA
jj new @-; jj branch create A2
echo Y > fileA

jj new @-; jj branch create B1
echo Z > fileB
jj new @-; jj branch create B2
echo W > fileB

# jj new A1 A2 B1 B2 would work at this point already,
# but I find the following easier to think about:

jj new A1 A2; jj branch create conflictA
jj new B1 B2; jj branch create conflictB
# conflictA has a conflict in fileA, no change to fileB
# conflictB has a conflict in fileB, no change to fileA

jj new conflictA conflictB
# The conflicts in fileA and fileB should have 2 sides
# each, but currently will have more sides.
cat fileA
cat fileB

[ilyagr]

Thank you very much! The new update_from_simplified worked out very nicely.

I had a few last comments for tests, all minor. Please also wait for Martin to approve.

[martinvonz]

Thanks again for this! Looking forward to this getting released.