I used JJ for a bit, but I personally really, really dislike the anonymous branch approach it forces you into.
Branches are just useful conceptually, at least to me. For the same reason I like my documents grouped into folders.
Frankly - I think JJ just ended up taking up far more mental bandwidth than git. Simple operations need generated ids, commands require complicated input (ex - the entire revset thing), I have to be constantly thinking about the tool and its structure.
It feels really oversold to me. It's solving problems for people who live in source control, not problems for people who just want snapshots of code every now and then. Hell - just look at some of the example commands from the suggested tutorial:
jj new ym z r yx m -m "merge: steve's branch"
jj log -r 'ancestors(trunk, 2)'
jj new o
jj log -r '@ | ancestors(remote_bookmarks().., 2) | trunk()'
---
With all due respect, if the intro tutorial to your tool includes a command having to literally write function names in quoted commands, or run a command with fucking 8 (EIGHT!) arguments... You've jumped the shark.
Not trying to harsh anyone's buzz - if you like it... great, it's clearly quite powerful. But it misses the mark for me. I want "just powerful enough" with minimal mental overhead.
I wrote that tutorial, and literally only one of those is relevant to my day to day work: jj new o, which means “make a new change on top of the change named o”. Yes, if you remove the context that “o” is on your screen and highlighted, it looks complex.
It’s the same with the other “jj new” command: you’re producing a merge by giving it every branch you want to merge together. If you’re merging five branches into one, you need to provide five identifiers for those branches. It could not be simpler than this. And -m adds a message, same as git.
The other two are showing off the power of the revset language; you’re not typing this stuff in yourself more than once, and if you are, you use an alias so that it’s shorter and easier to use.
Sure I'm definitely not playing fair, but I am cherry picking from the intro tutorial you put together, so I'm not going crazy either :P
I think my primary issue is that jj feels like it wants to control how I work more than git does.
Mentally - I just don't want to have to think about changes as often as jj seems to want to think about them. And maybe it's an intro phase, or a thing you eventually build past (I only played with it for a week or two) - but it felt like a lot of focus went intro structuring my work, instead of doing my work.
Basically - the vibe I got from it was: if you're a person who really likes making checklists, or complex tickets with subtasks and groupings and labels - jj is something you're going to like. If you're just interested in writing code and not so interested in source control outside of the ability to occasionally "snapshot this folder"... it's probably not going to be your thing.
> The other two are showing off the power of the revset language; you’re not typing this stuff in yourself more than once, and if you are, you use an alias so that it’s shorter and easier to use.
This is exactly my point. I use git every day on the command line. I have ZERO aliases for it (seriously). If my source control tool has reached the complexity where I feel like I need an alias for commands in it... it's gotten too powerful. And git is definitely not "off the hook" here, it's absolutely got the same deep end, and if you live in that space, sure - jj might be really nice. But I strive to avoid living in that space.
basically: I don't want to do jujitsu, I want to do the occasional somersault and call it a day.
This is a bizarre take, as most jj users just take your paragraph above and do a s/jj/git.
The benefit most people find in jj is that you can do stuff easily without having to think much.
There is no separate concept for stash and index (and yet you still have them in jj, and use them without giving them special names).
In principle, there's no real distinction between merge and commit.
You don't need to know the difference with/without --hard for git reset. You just do a "jj undo" no matter what.
Merge conflicts are not stress inducing. And if you're in the middle of an ugly merge conflict, you can just say "Screw it all" and quickly get back to before you did the rebase/merge - just keep hitting "undo" until you get there.
jj literally has a much smaller cognitive overhead than git does.
That said: you should use the tools you like to use.
`jj` is a tool trying to amplify the strengths of git and strengthen its weaknesses. `git rebase` being just one of the many quirky commands. Yes, `jj` requires some rewiring of your brain, but once you get over the initial bump its pretty slick.
Also, I use `jj` everyday exclusively. And I have written `revsets` like 4 times in total.
`jj` is a wrapper around git and offers a much better dev-ex for managing changes.
it has features like:
- conflicts are first class citizens
- `rebase` is the default mode; there is no need for an interactive rebase mode.
- all descendant changes automatically rebase
- a much more intuitive version of `git reflog`. in `jj`, we have `jj op log`
- cheap branching: branches in `jj` are just tags (or bookmarks) that can be moved around