Better approaches to resolving conflicts?

[keysmashes]

Merge conflicts are a struggle for me with jj.

• I don't really understand how jj decides which side of a conflict is which; git labels them in the conflict markers (commit hash or branch name or HEAD or something), but jj just calls them "side 1" and "side 2". If I'm rebasing a change I haven't worked on for a moment, I might not remember which side is mine and which side is changes introduced by new ancestor commits. (ah, I've just found Can conflict markers indicate what revision each version originates from? #1176 🫠)
• In a similar vein, I don't understand why sometimes the diff of base -> side 1 is shown, but other times it's the diff of base -> side 2. (Perhaps FR: conflict-marker-style base-with-diffs #6021 is related... if a base-with-diffs style were available, many conflicts could be resolved by starting with the base, then reconstructing each change in your head and applying them in order by hand. I realise that in practice this is already possible with a 2-sided conflict by applying the diff to the snapshot, but it's not immediately obvious that this is actually the case – it feels like there should be useful information encoded in the order that they're presented, and it's offputting that it seems arbitrary.)
• I have no idea how to properly use the builtin editor that jj resolve spawns for conflict resolution. For splitting apart a commit, it seems intuitive, but when resolving a conflict, it presents me with some added lines followed by some removed lines followed by some added lines, without even the meagre context of "this is one side, this is the other" you see in the materialized files, and every time I've used it I've ended up with leftover junk lines around the resolved parts that I end up having to clean up by hand.
• To check that I resolved a conflict correctly, I've started digging into jj evolog for the relevant commit, and comparing my resolution to the last non-conflicted version. It would be really nice to be able to do that without copy-pasting a commit hash into jj show – this is kind of FR: revset functions for traversing the obslog #4129, I guess...

Right now I'm considering setting ui.conflict-marker-style = "git" just so I can use the PyCharm conflict resolver. How does everyone else do this?

[scott2000]

This doesn't address most of the issues you mentioned, but if you're using a colocated repo, I think you could use the PyCharm conflict resolver without changing the conflict markers actually (at least that's how it works for IntelliJ Idea). Like a "Git > Resolve Conflicts" option should appear if the parent of the working copy has a conflict I think?

Personally, I use the default conflict markers and just apply the diff to the snapshot to resolve the conflict usually. I think jj chooses which side to show as a diff by seeing which side would have a smaller diff, which is why sometimes it's the first side and sometimes it's the second side.

[ocharles]

Something that has really helped me has been to stop caring about which side means what, and instead to focus on the actual conflict resolution itself. jj gives you two parts per conflict: a diff part, and a normal code part. The method to resolve a conflict is to manually apply the diff to the other side. I didn't realise this at first! But when I started to follow this method, I couldn't go back - it makes resolution so simple. I just have to spend a second parsing the diff to see what the change is actually doing, and then reapply it in the different, conflicting context. I'm not sure how much this helps, but if you weren't aware of the "how" to use conflict markers maybe this helps!