Add another way to resolve merge conflicts with Meld

[amiryal]

I never tried to contribute my three_meld tool back to Git because it is ugly (with all the shell escaping). With JJ it is much simpler, the shell is not involved.

Checklist

If applicable:

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

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[ilyagr]

Interesting idea! I'll try this out.

[amiryal]

I am letting this PR sit open for now, if you don’t mind. Recently I had an incident where jj diffedit actually was easier to reason about and work with than jj resolve for the same conflict.

My current thinking revolves around trying to organise the myriad different commands in JJ that might have been expressed as arguments to just a handful of more expressive commands. So many commands to move changes around, only differing in how you express the desired change to them and in how change_ids get reorganised as the outcome.

[ilyagr]

Recently I had an incident where jj diffedit actually was easier to reason about and work with than jj resolve for the same conflict.

This does happen regularly to me as well for simpler conflicts, but I often appreciate jj resolve as well.

[ilyagr]

I've been thinking a bit about possible ways to set up conflict resolution with a diff editing tool.

Here is the simplest one (call it A, I think I also prefer it at the moment):

After the resolution, it'd look like the following. Note that you can consult the left side to double-check your work:

A variation (call it B), in case the previous version is not clear enough for long conflicts:

And here's a three-pane possibility (call it C). (I later realized the Git-style merge conflict is in the wrong order in my fabricated example, the top and middle should be switched).

After resolving, it'd look like this:

[joyously]

I find it very confusing to mix conflict markers with Meld. The markers are showing two different versions in one place, so comparing that to one or the other is a bit strange. I think if Meld is involved, it should just be between the two clean versions, with no conflict markers. And they should be prominently labeled, but I know that's harder to do in an external tool.

[ilyagr]

I think if Meld is involved, it should just be between the two clean versions, with no conflict markers.

You can already get that using the normal meld tool for jj resolve. You can get a better version of it with 4-pane merge resolution tools (that is, tools that show the base of the conflict, the two sides, and the merge result in separate panes) like kdiff3, Beyond Compare, or even vimdiff. These are not going away. (It was the first feature I ever worked on with jj :) ).

On the other hand, while I think jj's favorite way of showing merge conflicts is more confusing at first, it seems to be very effective once you are used to it in many cases. Personally, these days I seem to prefer it to 4-pane merge tools often.

The fundamental reason is that, if I see the base of the conflict and the sides separately, I often have to diff the base and one of the sides manually (in my head), and then to apply that diff to the other side. jj's presentation of the conflict does the first of these steps automatically. (There are also some conflicts where jj's presentation does not help, especially when the base of the conflict has no useful information, but it does help in most cases).

Perhaps we should document and explain it better, I did have to discover all of this on my own and think about it before I got used to it.

In any case, I'd like there to also be a way to resolve conflicts with the focus on showing a side and a diff from it. One motivation for the above is that I miss being able to see my conflict resolution and the original conflict at the same time.

And they should be prominently labeled, but I know that's harder to do in an external tool.

I'm thinking of trying to improve this situation slightly in https://github.com/martinvonz/jj/issues/1176 (which I won't solve completely). Unfortunately, creating meaningful labels all the time is hard, mostly because jj's conflicts can be manipulated in complicated ways, and it's hard to have consistent rules for what the label should be in every case.