senekor
Joined 1 year ago
Joined 1 year ago
Before I started using Jujutsu, I didn't have any pain points with using Git. I didn't understand what all the fuss was about. Git works well! So I totally understand how most Git users have that same reaction when hearing about Jujutsu.
I think the reason I even tried it out in the first place was because Steve Klabnik wrote a tutorial about it. I have a lot of respect for him, because the Rust book is really good. So I though: If Steve thinks it's worth it, I should probably check it out.
Now that I'm used to jj, going back reveals like 100 things that are immediately super annoying when using git. I don't feel like writing it all down TBH. :-) In a general sense, Jujutsu get's out of your way much better than Git. There are a lot of situations where Git blocks you from continuing to work. Have a merge conflict? Stop working, fix it right now. Want to check out another branch? Nu-uh, clean up your dirty worktree first. jj doesn't do that. Have a conflict? I'll record it in the commit, fix it whenever you like. Checking out another branch? No worries, I'll keep your work in progress safe in a commit.
And then Jujutsu came along and casually doubled my VCS productivity. I didn't see it coming!
> - i'm forced to be "strict" with my changeset since there's no `git add -P`
Check out the command `jj split` and possibly `jj squash --interactive`.
> - bookmarks are a pain to keep up-to-date with `jj new`
There's a neat alias a lot of people use:
```toml [aliases] tug = ["bookmark", "move", "--from", "heads(::@- & bookmarks())", "--to", "@-"] ```
It finds the closest bookmark and moves it to `@-`. Pretty much exactly what you want when adding more commits on top of an existing branch.
Jujutsu is Git-compatible, so there's nothing to lose. It can literally create the `.git` directory next to the `.jj` directory to fool all your existing tools into thinking this is a git repository.
There are a few limitations... Jujutsu currently ignores submodules, for example. So you have to run `git submodule update` sometimes. And when you yourself update the submodule, you need to `git commit` instead of `jj commit`.
Git LFS is also not supported. Apart from that, it's smooth sailing AFAIK.
> I think this is a very interesting concept, but I think it could go farther with some more targeted marketing along these lines. Of course, if Git power users are not Jujutsu's intended audience, then this comment may be irrelvant.
Git power users are definitely part of the target audience, most Jujutsu users today are retired Git power users. Because that's not the target audience of my tutorial though, I didn't write much about that. Some of the features jj users are most excited about include: - Conflicts are non-blocking. Merge and rebase always succeed, conflicts are recorded in the commit itself. You can work on something else and come back later to solve them. - There is `jj undo` and `jj redo` which work like Ctrl[+Shift]+Z in GUI apps and text editors. They affect the whole repository, because that has basically its own linear history. Reflog on steroids, basically. - `jj absorb` can find the most recent commit that touched the same lines and squash your changes into it. It's magical if you're working on several things in parallel (by merging the separate branches together, just for development.)
These are just some examples that come up the most in the "appreciation" channel on the Jujutsu discord.
> I think one of Git's great weaknesses is its unfriendliness to newcomers (jargon, deep features, lack of discoverability, lack of accessible GUI frontends), so there's probably a lot of potential for a VC solution that is easier for a newcomer to jump into.
Yes! I think Jujutsu has a lot of potential there as well. But there's a lack of learning material for that target audience... hence why I wrote this tutorial :-)