Live data from Hacker News

Switch to Jujutsu Already: A Tutorial

stavros.io

31–40 of 164 posts

Re: Switch to Jujutsu Already: A Tutorial

#31
post #24
post #9

Earlier quoted context omitted.

I don't hate git, I like it fine and, until recently, used it exclusively on all my projects (I still use it non-exclusively). Here's an article that's written from that viewpoint: https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut... That having been said, I didn't hate Subversion either. It was fine.

> I don't hate git Idk man, the first two paragraphs of the article very much make it sound like you hate git. > Over the past few years, I’ve been seeing people rave about Jujutsu, and I always wanted to try it, but it never seemed worth the trouble, even though I hate git.

Fair enough, I'll clarify what I actually hate.

Re: Switch to Jujutsu Already: A Tutorial

#32
post #25
post #22

Right in the first paragraph. > Needless to say, I just don’t get git. What is there not to _get_, honestly? And why is jj so easier to get? The author seems to focus on how great it is to make changes to your commit history locally, and that you shouldn't worry because it's not pushed yet. The thing is, I don't want automatic. Automatic sucks. The point of version control is that I am able to curate my changes. The…

If you don't want automatic, you shouldn't use git. It does too many things automatically, like update your branches' heads whenever you commit, for example.

And if I don't want that I can detach the HEAD. This isn't to much different. The only thing that changes by using branches is that you have a nice name, it prevents the commits from being GCed and it provides a default name on push.

Re: Switch to Jujutsu Already: A Tutorial

#33
I use a gui for 90% of my workflows. Another 9 percent points are hitting back in my console history to rerun commands, never mind if git or jj or POSIX that affect my working dir or index state.

What am I supposed to do, use the UI plus jj, and prompt an LLM to use which: git, or jj, in case I am too lazy to think of the right command in the remaining one percent of cases?

But in general, I like the "less states and DVCS features than git" approach, but would not switch back to mercurial just to avoid the whole "should we rebase or create merge-commits" discussions in our teams due to having a single default that might not be optimal for everyone, but just works.

Re: Switch to Jujutsu Already: A Tutorial

#34
post #30

I feel like anyone who spends just a couple of hours learning git will have a much better mental model than the crappy "Assembly line" model from the article. Your real mental model of git should be an acyclic directed graph where the nodes are commits and the edges are ancestry. Commits represents snapshot of the project's state. Tags and branches are just text pointers to commits in the graph. If you use this menta…

Totally agree on the DAG point of view, but I would argue that for different people you need different analogies/models to make it click. I would argue that pointing towards graph theory might help people that have a formal CS or maths education, but not necessarily folks that went through bootcamps, switched from design roles, have a biology background (e.g. bioinformatics) or do statistics (e.g. in medicine or psychology)

Re: Switch to Jujutsu Already: A Tutorial

#35
post #27

I don't really understand the appeal of jj as someone who uses sublime merge [0]. It has good support for submodules, a lot of the editing commits (messages, squash, move etc...) is really easy and I can also see and edit my stashes directly. Is there any benefit to jj compared to this? [0] https://www.sublimemerge.com/

committable conflicts give you painless rebases. if you know about rerere, try jj; if you don't, it might not be worth it.

Re: Switch to Jujutsu Already: A Tutorial

#36

I just don't have enough pain points with Git to move to something new. I don't have a problem remembering the ~5 commands I need most on any given workday. Between stashes, branches, temporary commits I later rebase, and recently worktrees, I don't lack for anything in my usage. It's universally used across both my public and corporate life, and neither does anyone need to learn a new tool to interact with my code b…

The best thing that could come out of jujitsu is git itself adopting the change-id system (which I believe I read somewhere is being considered). If you actually take time to learn your tools and how they're intended to be used, there's really not reason to learn jj IMO

Re: Switch to Jujutsu Already: A Tutorial

#37
post #13

Earlier quoted context omitted.

Yeah I definitely hated Subversion, which helped push me to try Git back in the day. Actually, back then I was an `hg` guy. That battle was lost long ago though. I think you linked to the same post as OP, though?

I wrote the post, so that's a post from the perspective of someone who doesn't hate git :P I used bzr after SVN, but my larger point is that it's all fine, the question was whether you want to go through some short-term learning for long-term gain, or if you want to keep using what you know. Either is fine, I'm still using vim as my editor, for example.

SVN was not fine. Branching took forever (all the copying). And the space that required ... In fact, lots of things took forever on large-ish repos. Remember that everything required the server and network and disk speeds were slower back then. And just a commit could destroy your work if you got stuck in a conflict resolution. So you'd have to copy all the files you changed to a backup just in case, then delete them if the resolution went OK etc.

Was it better than CVS in some way? Sure.

But git is just better in so many ways. Back in the day I used git exclusively with git-svn at a place that was still stuck with SVN and I had a blast, while everyone else didn't. I just never had any of the problems they did.

I'm not entirely sure what pain people speak of with git. I found the transition very natural. And don't come talking to me about the "weird command syntax". Some of that was specifically to be compatible / "intuitive" / what they were used to for people coming from tools like SVN.

Sure you gotta learn about "the index", understand that everything is local and that you have an origin and local copy of all the labels (also sometimes called branches or tags) you can attach to commits. That's about it for the normal and regular use that someone would've had with SVN.

Re: Switch to Jujutsu Already: A Tutorial

#38
post #13

Earlier quoted context omitted.

I wrote the post, so that's a post from the perspective of someone who doesn't hate git :P I used bzr after SVN, but my larger point is that it's all fine, the question was whether you want to go through some short-term learning for long-term gain, or if you want to keep using what you know. Either is fine, I'm still using vim as my editor, for example.

SVN was not fine. Branching took forever (all the copying). And the space that required ... In fact, lots of things took forever on large-ish repos. Remember that everything required the server and network and disk speeds were slower back then. And just a commit could destroy your work if you got stuck in a conflict resolution. So you'd have to copy all the files you changed to a backup just in case, then delete them…

Well you can either have a viewpoint of "the current thing I use is fine because I'm used to the warts" or "it's not fine because other things exist".

It can't be that SVN is bad and git is better but also that git is fine even though jj is better.

Re: Switch to Jujutsu Already: A Tutorial

#39
post #22

Right in the first paragraph. > Needless to say, I just don’t get git. What is there not to _get_, honestly? And why is jj so easier to get? The author seems to focus on how great it is to make changes to your commit history locally, and that you shouldn't worry because it's not pushed yet. The thing is, I don't want automatic. Automatic sucks. The point of version control is that I am able to curate my changes. The…

Hmm, what guards and rails?

There are some convention people follow when working with git to make it safe to use. But those aren't git's features -- they are ways to avoid confusion.

Re: Switch to Jujutsu Already: A Tutorial

#40
In the past 2 months, I saw 3 articles about JJ.

Always the same starting point: "I don't understand how git works".

If you can't understand git, one of the most used tool in the whole industry, this is a *you* problem. You MUST take the time to understand how it works properly. Every job you'll get and every projects you'll work on will use a Version Control (at least I hope).

Abstracting this knowledge by using a tool that does things quite differently won't help you at all on the long run.

Post reply on HN