Comment by horsawlarway
21 hours ago
> If you cherry pick complicated commands, and remove all context, sure, they look cryptic.
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.
So, as a long-time mercurial users, revsets in jujutsu were a major feature for me. And if you don't want to use them, don't. But if you are looking to treat your VCS DAG as a queryable database they are awesome. And, they are great for avoiding having to chain a bunch of commands together, inefficiently, to get the same effect. Although you still can do that if you really want to. Just like you don't have to use jq to query JSON - you can do terrible cursed things with grep and awk and sed and it'll even work for simple cases. But you might want to give jq a spin - and really there are strong parallels in how they 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.
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.
I also have zero aliases for git, and for jj. (I used to have one joke alias.)
That said: you should use the tools you like to use.