`DiffviewMergeFiles` not showing all files for `jj`

[pksunkara]

Using the following jj config:

[merge-tools.diffview]
program = 'nvim'
merge-args = ['-n', '-c', 'DiffviewMergeFiles $output $base $left $right']
merge-tool-edits-conflict-markers = true

I am only seeing the file-by-file. What is needed for to be done in either jj (I will contribute) or here such that I can open the merge tool with all the files (in file panel) just like the screenshot in the README?

[dlyongemallo]

This can't really be fixed on the plugin side, but requires jj's merge-tools interface to invoke the tool using some kind of "batch" mode. Right now, the merge tool (hence the plugin) is invoked once per conflict file. Please file an issue against jj and link this issue.

[pksunkara]

Done, created the issue

[pksunkara]

Quick question to help design the feature for the future.

If multiple files are opened, once a file is resolved, should it disappear from the list or just marked as resolved?

---

By the way, currently the merge tool needs to be quit twice for each file opened. One q to quit the diffview and then another :q to quit the nvim. Including the initial :w, that is a lot of keystrokes to continue to the next file.

If we were to add a shortcut to do all this (w?), that shortcut should work differently for the batch merge tool by cycling through conflicted files and only quitting diffview only if all are resolved.

WDYT @dlyongemallo?

[dlyongemallo]

If multiple files are opened, once a file is resolved, should it disappear from the list or just marked as resolved?

In the current multi-file merge UI, the file would move from the "Unresolved" to "Resolved" section. This mirrors the git "Working tree" / "Staged" sections, except jj won't need the user to mark the file expllicitly as it does resolution based on content contents (whether conflict markers still exist).

I don't understand why you'd need to add a shortcut to cycle through conflicted files when that can already be done using j/k/<tab>/<s-tab>.

Why are you not just typing :wq to quit nvim? Why are you quitting the plugin first, then the editor?

[pksunkara]

Why are you not just typing :wq to quit nvim? Why are you quitting the plugin first, then the editor?

When using as mergetool, after editing the MERGED and doing :wq is closing the only the MERGED buffer. It is not closing the whole nvim.

I don't understand why you'd need to add a shortcut to cycle through conflicted files when that can already be done using j/k//.

In multi file merge UI, I am saying that saving the MERGED buffer using w and if it has no further conflicts, should either immediately go to next conflicted file. If this is not possible to add, have a shortcut that does both saving and cycling in one stroke instead of needing two like what you wrote.

[dlyongemallo]

When using as mergetool, after editing the MERGED and doing :wq is closing the only the MERGED buffer. It is not closing the whole nvim.

You could just map <leader>w (or whatever) to :wqa yourself, if you're so inclined:

keymaps = {                                                                                                                                                                         
  diff3 = { { "n", "<leader>w", "<cmd>wqa<cr>", { desc = "Save merge & exit" } } },                                                                                                 
  diff4 = { { "n", "<leader>w", "<cmd>wqa<cr>", { desc = "Save merge & exit" } } },                                                                                                 
}

In multi file merge UI, I am saying that saving the MERGED buffer using w and if it has no further conflicts, should either immediately go to next conflicted file. If this is not possible to add, have a shortcut that does both saving and cycling in one stroke instead of needing two like what you wrote.

Why don't you just use :DiffviewOpen instead of :DiffviewMergeFiles for merge conflict resolution? I think you could just add an alias to run nvim -c DiffviewOpen. Then you can just set auto_close_on_empty to true.

[dlyongemallo]

@pksunkara Can you try #288 and use DiffviewOpen instead of DiffviewMergeFiles? It re-uses the staging machinery of the git VCS adapter to carry out a multi-file merge for jj. (It's a bit strange to repurpose the s = staging keymap, but we can think of it as s = save.)

[pksunkara]

Sorry, but how do I use DiffviewOpen to open in merge mode?

[dlyongemallo]

Just type :DiffviewOpen from inside neovim when the working copy is on a conflicted change. Or if you're in the command line, start neovim with nvim -c 'DiffviewOpen'. I think you have to set conflict-marker-style to git in the config.

I don't use jj, but I guess jj new and jj rebase are typically the commands that result in a merge conflict.

[pksunkara]

Just type :DiffviewOpen from inside neovim when the working copy is on a conflicted change. Or if you're in the command line, start neovim with nvim -c 'DiffviewOpen'

Weird, I did try it like that in a conflicted change.

1. It opened all the other non-conflicted files too (which I assume is intentional)
2. I didn't see the s keymap anywhere in any of the three windows.
3. Conflict markers were jj style even though I had the config under merge-tool

I am not sure if I am doing it the right you wanted me to. Did you mean that I should use jj resolve with DiffviewOpen as the merge tool instead of DiffviewMergeFiles?

[dlyongemallo]

Have you ever tried to resolve a merge conflict using DiffviewOpen in a git repo? It's the same process.

1. Yes, this is by design. All the files in the merge are shown, divided into resolved and unresolved sections.
2. Are you in the file panel? g? should tell you if they're available.
3. I think conflict-marker-style = "git" should be under the top-level [ui] section, not merge-tool. The whole point is that it isn't going through the merge tool mechanism.