Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switch to Jujutsu Already: A Tutorial

stavros.io

Post reply on HN
Print view View original

71–80 of 164 posts

Re: Switch to Jujutsu Already: A Tutorial

#71

Post by angiolillo »

jdmg94 wrote: post #21

"Git is too hard" is never a good argument to promote the use of a different tool. I use git on the terminal exclusively, never had an issue amending a commit or rebasing a branch, or even dealing with conflict resolution most of the time I just use one of the automatic strategies.

> "Git is too hard" is never a good argument to promote the use of a different tool.

Really? Pointing out that a tool is difficult to use seems like an excellent argument to promote the use of a different (supposedly simpler) tool.

Specifically in the case of git, I'm glad it was not difficult for you, but it is undeniable that it is a very difficult tool for many people to learn.

Re: Switch to Jujutsu Already: A Tutorial

#72

Post by stavros »

karmakaze wrote: post #41

> Needless to say, I just don’t get git. I never got it, even though I’ve read a bunch of stuff on how it represents things internally. I’ve been using it for years knowing what a few commands do, and [...] > If you don't like Jujutsu, you're wrong It would be much more convincing if they had any idea of git that they were comparing it to.

Except, the fact that I have no idea of git after 20 years of use, whereas I have a great idea of jj after two months is exactly the point.

Re: Switch to Jujutsu Already: A Tutorial

#74

Post by stavros »

et1337 wrote: post #42
umvi wrote: 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…

I think the author is one of those folks who were able to fully grasp the beauty of the Git data model for the first time by switching to Jujutsu. It makes it easier to see the “DAG of commits” vision than Git with its index and stashes and confusingly named commands with fifty flags.

Yeah, exactly, and I've fruitlessly read too many guides on git's data model.

What was holding me back turned out to be the fact that git has too much magic (it updates branches automatically when you commit, rebasing "does stuff", conflict resolution was just arcane).

Jj exposes all that into simple, composable principles, making everything click.

Re: Switch to Jujutsu Already: A Tutorial

#75

Post by tharkun__ »

stavros wrote: post #66
tharkun__ wrote: post #60

Earlier quoted context omitted.

Except that it has to first be true that jj is better ;) You start out the article with hate for git without explaining what you actually don't like, then here on HN say "I don't hate git". A command called `fuckgit`? Because you need to re-clone? What are the things you commonly do that require this? I've never encountered it. Maybe you're just too advanced a user for git and jj really is better for you. But for us…

> You start out the article with hate for git without explaining what you actually don't like I start out the article saying I never understood git, and why does it matter what I don't like? That would only matter if I were trying to say that git is bad, but I'm not making a comparison. I just think jj is better-designed, and that you should try it. > Some of the benefits you tout, like "editing a commit and you don'…

    Your comment is coming off as a bit defensive
Your article is coming off as a bit offensive ;)

    I didn't write my article to attack git [...] I wrote the tutorial to help.
Except you didn't write a tutorial. You wrote an "I hate git and jj is better and if you think otherwise you're wrong" article.

Blue speech bubble with literally the text: "If you don't like Jujutsu, you're wrong". This is text. There's no "tongue in cheek" voice and body language here, even if potentially you meant it that way. But given how the article itself starts, I don't think there was any of that to transport :shrug:

    Needless to say, I just don’t get git
Actually, it does bear saying. And I do think that if you say "everyone that doesn't think jj is better is wrong" you have to explain what you really don't like or get. No it's not needless, because not everyone has your experience. I really do not understand your pain points unless you explain them, because I've never felt them. Either because I did understand the part you didn't, because I don't need to understand that part to use it well (cutting the decision/knowledge tree in your head is a skill by itself I've found over the years - sometimes you do have to accept magic! E.g. I don't need to understand exactly how any specific LLM works to use it well) or because I simply never had a need for the kinds of feature that trip you up.

Re: Switch to Jujutsu Already: A Tutorial

#77

Post by 1718627440 »

barrkel wrote: post #62
jakebasile wrote: post #8

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…

If you've ever lived in a world of stacked commits with develop on main (i.e. not gitflow, no feature branches), combined with code review for every commit, git will soon start to aggravate you. Git doesn't make rebasing a chain or tree of commits pleasant. Git records merge resolutions and can reuse them, but it doesn't do the same thing for rebases, making them more repetitive and tedious than they should be. When…

> Git records merge resolutions and can reuse them, but it doesn't do the same thing for rebases

Since when does rerere not work with rebase anymore?

Re: Switch to Jujutsu Already: A Tutorial

#78

Post by angiolillo »

oxceedo wrote: post #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 t…

> You MUST take the time to understand how it works properly.

Unfortunately, I agree.

It is both ubiquitous and so unnecessarily complex. The fact that all developers are required to memorize at least a few of its inscrutable incantations reflects poorly on the industry and on the judgement of its practitioners.

Re: Switch to Jujutsu Already: A Tutorial

#79

Post by karmakaze »

stavros wrote: post #72
karmakaze wrote: post #41

> Needless to say, I just don’t get git. I never got it, even though I’ve read a bunch of stuff on how it represents things internally. I’ve been using it for years knowing what a few commands do, and [...] > If you don't like Jujutsu, you're wrong It would be much more convincing if they had any idea of git that they were comparing it to.

Except, the fact that I have no idea of git after 20 years of use, whereas I have a great idea of jj after two months is exactly the point .

Fair enough. I'll reconsider if my git workflow is impacted to a point where it shows up to be non-negligible under Amdahl's Law.

Edit: read more of the post and I still don't see the big deal. It's like rebase/edit with a bit less typing.

Re: Switch to Jujutsu Already: A Tutorial

#80

Post by joshheyse »

In the age of Claude Code and other MCPs, the last thing I want is my commit history to be mutable. I've added instructions to Claude which make a commit before each modification with a summary of the conversation that caused the change. Once I'm happy with the work, I squash the commits and push up. (Which I believe is more or less equivalent to the jj workflow.)
Post reply on HN