Add a TUI for editing diffs about jj HOT 16 CLOSED

Thanks. I just tried vimdiff again on a diff (i.e. two input files). I didn't see any instructions anywhere and the somewhat common '?' shortcut (shift+/ on my keyboard) didn't work either. That's why I said earlier that I don't find it intuitive. Mercurial's UI for hg split, on the other hand, has a line at the top with some brief instructions and tells me I can press '?' for more detailed help. I'd really like my diff/merge tool to have something like that.

from jj.

PR for the TUI which I'm working on: arxanas/git-branchless#343

Embedding the git-crecord Python library/binary might be a pragmatic option, too, although it's GPL-2-only.

from jj.

Update: #1211 added variable expansion, and $left/$right is now required unless ui.diff-editor is a program name.

ui.diff-editor = "code"  # equivalent to ["code", "$left", "$right"]
ui.diff-editor = ["code", "--wait", "--diff", "$left", "$right"] 

(I have no idea about the option to forcibly open a diff editor.)

from jj.

This would also be useful for git-branchless for the same reasons.

The TUI which I was used to with hg split met the majority of my needs, in which the diffs are displayed inline and you just select the lines you want to keep. For more complicated cases, it might be better to allow the user to shell out to their mergetool for a given file, to keep implementation complexity down.

from jj.

This would also be useful for git-branchless for the same reasons.

Yes. If I start working on a TUI for editing diffs, I'll probably start making it part of jj, but then I hope to make it standalone. That probably involves moving out diffing to a separate crate so it can be depended on from both jujutsu-lib and this new diff editor.

The TUI which I was used to with hg split met the majority of my needs, in which the diffs are displayed inline and you just select the lines you want to keep.

That's also the UI I'm used to. The biggest problem I have with that is that it's really hard to edit the patch itself (after pressing e in that UI). I prefer how Meld instead lets you edit the end state itself. Inline diffs may still be best for most cases and it's just the "edit" action that should be different. I think hg's interface was too tailored to editing the literal patch that it wasn't possible to make that change there. I'd like the diff editor to get two full texts as input and figure out the diffing itself.

For more complicated cases, it might be better to allow the user to shell out to their mergetool for a given file, to keep implementation complexity down.

Except that there I don't know of any good terminal-based mergetool... :(

from jj.

What are the deficiencies of the terminal-based mergetools which you've used?

from jj.

I don't think I've used any at all. I've started vimdiff but I couldn't figure out what to do after starting it. Last time I looked for tools, I remember reading about another tool called sdiff, but I'm not sure that even has a TUI.

Can you recommend any?

from jj.

I was using vimdiff as launched from git mergetool. It looks like this (not sure if it's what you're seeing):

The bottom window is the actual buffer you want to edit. The top three show the "local", "base", and "remote" snapshots of the file for your reference (i.e. the components of the three-way diff). The diff coloration updates as you edit, and all the buffers should scroll in sync. You could also simply edit one of the above three windows and overwrite the target file, if you prefer not to use the conflict marker mechanism.

from jj.

As an additional data point, git-crecord offers a TUI for selecting changes to stage/commit on an line-by-line basis. IIUC it doesn't allow actually editing the diff contents, but it has a dynamic expanding/collapsing interface that may be an interesting feature to consider (although a one-hunk-at-a-time approach like what git add -p does would likely make that unnecessary).

from jj.

Thanks. I'd seen git-crecord, and I've used the orginal implementation for Mercurial a lot, but I had somehow not considered using it with jj :) Most of the time you don't need to edit the diff, so it seems fine if that's not supported to start with. I haven't spent much time looking through the code, but I would think most of it is reusable outside of git. I know Mercurial's crecord code actually works on the diff itself, while jj's configurable diff-editor works on two states (which tools like meld expect as input). We could probably create a wrapper that calculates a diff and calls some lower-level functions in git-crecord, and then applies the diff to the left input at the end.

Also, rumor has it that @arxanas is working on a TUI like this for (presumably for https://github.com/arxanas/git-branchless, but should be reusable).

from jj.

Is there a config to use VSCode for this in the meantime? I tried ui.diff-editor = "code --wait --diff $LOCAL $REMOTE" but that wasn't successful.

from jj.

Try something like this. ui.diff-editor doesn't support list of arguments nor "$variable" expansion right now.

ui.diff-editor = "vscode"

[merge-tools.vscode]
program = "code"
edit-args = ["--wait", "--diff"]

https://github.com/martinvonz/jj/blob/b22a6db7e7ec4bae901fe4586ec771a8a3d9e8b3/src/config/merge_tools.toml

from jj.

Thanks for suggesting something @yuja

FYI this does open VSCode with the files, but not a diff editor. But no great stress...

from jj.

VS Code doesn't support diffing directories out of the box, only one file at a time. I found https://marketplace.visualstudio.com/items?itemName=moshfeu.compare-folders that claims to be runnable from the command line, but I haven't tried it.

A script could also be written. I'm not sure what the best approach is, but it should be possible using diff -r or the Node.js library the extension I linked uses.

from jj.

Shall we close this? We now bundle scm-record into jj, and we can invoke external diff editors as desired. It's true that scm-record doesn't let you edit hunks directly, which is sometimes useful. It might be better to open a feature request for that specifically.

from jj.

Shall we close this?

Yes, I agree. Thanks for creating scm-record and the integration!

from jj.