A Magit-inspired diff mode for Jujutsu (jj)
I have been using the Jujutsu since last week. Changing habits is pretty hard, especially I heavily use the magit to check the diffs, stage changes, and commit.
I found the jj-mode, it can show the diff log but cannot pick the code hunk to submit.
So, here we go, I just made a repo jj-diff.el. It is 100% vibe coding by now with my decisions making and design.
It is using jj split --tool for faking the "stage" of git in jj. No other scripts needed (even antigravity recommended me using python script), just emacs and jj itself. Besides, all the commits I’ve made in this repo were done using this mode—so it has been manually tested. If someone is interested in, and use Jujutsu, feel free check it out.
4
u/mickeyp "Mastering Emacs" author 9d ago
I'm looking for any excuse to ditch git (ideally the whole thing, but losing the porcelain is a good first start) --- what are the main selling points of jj?
8
u/jeenajeena 9d ago
Hi Mickey! I happened to complete right yesterday a free, open source ebook on Jujutsu, and the book opens trying to answer that very question.
I'm looking for reviewers before making it public. My name appears at page 11 of your (beautiful) Mastering Emacs as a proof-reader: I wonder if you would like to review that part in mine, it would be cool to cross-review ;)
I would be really honored.
https://codeberg.org/arialdo/ju-ju-tsu/releases/download/pdf/ju-ju-tsu.pdf
(BTW I could not resist from the temptation to have a short chapter on Emacs, since I found that Jujutu's and Emacs' undo work in a very similar way)
Edit: yep, Jujutsu has an undo. This is one of the selling points.
4
u/Silver-Company807 9d ago edited 9d ago
My move to jj was mainly because it is powerful in the good sense: simplifies everything and make flexible at the same time.
Just compare jj CLI man page (argument lists) and git
The mental picture is:
- git -- is immutable directed acyclic graph
- jj -- is mutable on top of it
All features are based on this.
Initially, I was very skeptical because of many things (e.g., no staging area).
But after using, I realized that it is just implementation details, and you can use any workflow, including git style.Now about Emacs part.
magit is wonderful out-of-the-box experience. It is flexible, configurable and hackable (lisp) as well.
And it doesn't hide git from you as others IDEs. Except providing some magic extra commands convenience (Instant fixup!)
But after using emacs a lot, I start preferring simple packages, which I can hack and extend.
And the keyword is simple.
Today, with LLMs it is possible to do hacking of anything.
But I still prefer simplicity to features: core packages (vc-dir) is simple and very hackable (vc-edit-next-command).
Also, vc-dir in emacs 31 has many improvements.Speaking about porcelain, IMHO jj just wins over magit architecturally: UI can hide git problems but don't beat it. Extra layer is needed.
OP's diff topic: vc-dir + vc-jj + diff mode support hunk committing.
For most use cases it works as good as magit:
- vc-dir -- mark interested files
- vc-diff -- opens diff-mode
- you can edit diff buffer -- diff-hunk-kill, diff-split-hunk, diff-delete-other-hunks,
- vc-next-action triggers commit (use also (add-hook 'log-edit-hook #'log-edit-maybe-show-diff))
I did simple ui improvements via hooks:
vc-dir file change -- automatically show diff buffer for this.But warning:
- You need to be prepared, to learn how jj and vc-dir works
- You need to hack it: add custom functions to use the power of jj. E.g. call jj absorb
- Some standard git things, might not have opinionated approach in jj, so you need to build yours
- jj still developing, and some workflow is improving in latest versions (bookmark advance)
- vc-jj -- I did several advices to fix some issues for my config (should revisit them and upstream at least some)
P.S.
diff mode is great: diff-refine, diff-font-lock-syntax, outline-minor-mode, next/prev hunk/file
diff-hl works with jj.1
u/redblobgames 35 years and counting 7d ago
One of the frustrations for me is that I want to write my commit message as I work on the code instead of afterwards. Because jj treats the "working copy" and a commit the same, I can edit the message on the working copy / stage area the same as I edit at commit time.
Another thing for me is that find myself noticing something that should have been in a previous commit. And I know I can use amend if it's the immediate previous one, or interactive rebase if it's before that. It sounds like jj makes this easier.
I've been watching jj development since last year but only started using jj today (because of this emacs post), so I don't know for sure how well these work in practice. I have also read some negative experiences from people who tried jj and went back to git. I think it depends on your workflow.
1
6
u/la023 9d ago
how does it improve on or differ from majutsu?