upvoting not because I think the article is great, but because I want someone to tell me (a magit user) why jj is better than using magit to interact wit git!
I find JJ to make things much easier for me than Git:
- No staging needed, edit your commit directly in your working directory
- Rebasing is automatic, I regularly edit historic commits and the messages
- jj absorb will automatically split and merge hunks into related ancestry commits
- Defer conflict resolution; many conflicts are resolved later by splitting/squashing/moving commits/hunks further (possible only for first-class conflicts)
- No interactive rebase needed, since jj commands automatically rebase while editing historic commits, it feels like constantly living within an interactive rebase
- Easily refer to the same revision (change) across rebase commands by using a jj change_id, without scribbling down Git commit hashes that change across a rebase
- Easily undo (+redo) your last commands through the jj operation log without having to backup the entire git repo at each step
And jj-fzf (https://github.com/tim-janik/jj-fzf/) gives me every useful jj command with a single hotkey (e.g. Ctrl-P for push, Ctrl-N for a new commit with 1+ parents, Alt-B to edit bookmarks/tags, Alt-R to rebase, Alt-Z for undo, …) while browsing the log with commit+diff preview.
I am not an experienced magit user, (because I don't use emacs) so I can't really speak to this directly, but I can tell you what I understand to be the case.
Here's the motivation for jj, described by its creator (this will be on the FAQ in the next release:
The project started as an experiment with the idea of representing the working copy by a regular commit. I (@martinvonz) considered how this feature would impact the Git CLI if it were added to Git. My conclusion was that it would effectively result in deprecating most existing Git commands and flags in favor of new commands and flags, especially considering I wanted to also support revsets. This seemed unlikely to be accepted by the Git project.
Fundamentally, jj is a different VCS, not just a UI layer on top of git. And so there's a lot of differences, but they sort of sound more generic than specifically "vs what magit gives you."
I don't have time to be more lengthy at this exact moment, but I'll be curious to hear what others say, and I can come back and say more later if you're curious.
Lanedo|4 months ago
- No staging needed, edit your commit directly in your working directory
- Rebasing is automatic, I regularly edit historic commits and the messages
- jj absorb will automatically split and merge hunks into related ancestry commits
- Defer conflict resolution; many conflicts are resolved later by splitting/squashing/moving commits/hunks further (possible only for first-class conflicts)
- No interactive rebase needed, since jj commands automatically rebase while editing historic commits, it feels like constantly living within an interactive rebase
- Easily refer to the same revision (change) across rebase commands by using a jj change_id, without scribbling down Git commit hashes that change across a rebase
- Easily undo (+redo) your last commands through the jj operation log without having to backup the entire git repo at each step
And jj-fzf (https://github.com/tim-janik/jj-fzf/) gives me every useful jj command with a single hotkey (e.g. Ctrl-P for push, Ctrl-N for a new commit with 1+ parents, Alt-B to edit bookmarks/tags, Alt-R to rebase, Alt-Z for undo, …) while browsing the log with commit+diff preview.
steveklabnik|4 months ago
Here's the motivation for jj, described by its creator (this will be on the FAQ in the next release:
The project started as an experiment with the idea of representing the working copy by a regular commit. I (@martinvonz) considered how this feature would impact the Git CLI if it were added to Git. My conclusion was that it would effectively result in deprecating most existing Git commands and flags in favor of new commands and flags, especially considering I wanted to also support revsets. This seemed unlikely to be accepted by the Git project.
Fundamentally, jj is a different VCS, not just a UI layer on top of git. And so there's a lot of differences, but they sort of sound more generic than specifically "vs what magit gives you."
I don't have time to be more lengthy at this exact moment, but I'll be curious to hear what others say, and I can come back and say more later if you're curious.
kccqzy|4 months ago
2. `jj evolve` is excellent.
3. First-class conflicts. Even just deferring conflict resolution later is convenient.
steveklabnik|4 months ago