Live data from Hacker News

Defeating Git Rigour Fatigue with Jujutsu

ikesau.co

181–190 of 193 posts

Re: Defeating Git Rigour Fatigue with Jujutsu

#181
post #2

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can…

I think much of the problem with this thread is people trying to convince one way is superior/inferior. There are just multiple different ways of working. Some ways fit some people's mental models better. You're not going to get a definitive "jujutsu is better than git" or vice versa. You should accept that some people have no problems with what you've described using jujutsu, and likewise jujutsu users should unders…

> With git, I'd routinely go and delete old branches to declutter. With jj, there's simply no need to. The same with stashes. It's really nice not having to do that labor, and simultaneously not dealing with long lists.

wait what? how does this work?

Many of my stashes are tiny changes that need checked later - effectively, each stash entry is a quick TODO list. At some moment, for example once a major feature is done, I'll go a check every stash'ed entry and decide - maybe it's no longer relevant, maybe I should make a PR out of it, or maybe I should convert them to the branch if it's useful but needs more work. The branches are similar, but on longer scale.

The idea that you don't need to declutter your old stashes/branches seems absurd to me - it's like getting a huge box labeled "misc", and throwing every single thing in there. Sure, it's quick, but that's how you lose the important things you need to do, and find the useless junk instead of the actual thing you were looking for.

Re: Defeating Git Rigour Fatigue with Jujutsu

#182
post #116

Earlier quoted context omitted.

Culture change is hard. A lot of humans still don't use git too. Many do only when they are forced. And it's much easier for a professional to be forced to use LLMs than jj when it comes to versioning assist (not even comparable in mindshare but the obvious needs to be said sometimes). So unfortunately I'm afraid jj is not going to achieve critical mass before 99.99% of merges are done by AI which don't need jj.

That's the beauty of jj. It doesn't need critical mass. If the community remains small it's fine. If it blows up in adoption that's also fine. Also there are many ways to use llms. Some people control it at code review, but others control it as the VCS.

Sure just like any non-critical tool. It's optional.

LLMs will do most of the work anyways. And they don't need jj. Like I said, jj helps solving a human problem in an LLM era.

It's hardly worth using more of the precious LLM context with jj instructions when git does the job and is mandatory anyways.

Re: Defeating Git Rigour Fatigue with Jujutsu

#183
post #170

Earlier quoted context omitted.

I think that version control has reached a point where the next major evolutionary steps will be based on making history totally shared and immutable with history edits themselves being non-destructive versioned operations that can be browsed as higher order history.

That’s, uh, exactly how jj works!

I never absorbed that fact until now. Now, if it supported huge repositories with large files and binary files well, it could actually become a superstar.

Re: Defeating Git Rigour Fatigue with Jujutsu

#184
post #111
post #18

Earlier quoted context omitted.

You can also have you agent use jj with this skill https://github.com/danverbraganza/jujutsu-skill

Wow, that's really nice. I'm absolutely stealing that. Thanks!

You can't steal what's freely given!

My only ask--tell me how it sucks so I can make it better.

Re: Defeating Git Rigour Fatigue with Jujutsu

#188
post #182

Earlier quoted context omitted.

That's the beauty of jj. It doesn't need critical mass. If the community remains small it's fine. If it blows up in adoption that's also fine. Also there are many ways to use llms. Some people control it at code review, but others control it as the VCS.

Sure just like any non-critical tool. It's optional. LLMs will do most of the work anyways. And they don't need jj. Like I said, jj helps solving a human problem in an LLM era. It's hardly worth using more of the precious LLM context with jj instructions when git does the job and is mandatory anyways.

jj is in the training data for at least Gemini these days. My experience is it uses less tokens to do similar workflows with jj vs git because they are simpler.

Also, remember that humans aren't going away. The touch points are changing but they still exist. The VCS is a common touch point for many and my preferred one. For others I'm sure it's online code review tools. If an agent is operating under my name in my workspace I want to manage it within the confines of my workspace. Once it becomes more agentic and operates as it's own entity I'm sure I'll change my mind but that's not the case today.

Re: Defeating Git Rigour Fatigue with Jujutsu

#189
post #170

Earlier quoted context omitted.

That’s, uh, exactly how jj works!

I never absorbed that fact until now. Now, if it supported huge repositories with large files and binary files well, it could actually become a superstar.

> if it supported huge repositories with large files and binary files well,

In the open source context, it's limited by git here. But you can use jj with Google's monorepo, and so it itself is able to handle at least huge repositories (I don't know how big the largest files and binary files are in it, but I'm assuming that it has some of those too) well. That of course doesn't help you directly if you're not at Google, but the pathway is there.

Re: Defeating Git Rigour Fatigue with Jujutsu

#190

I'd like to give jj another go but I found the "all files must be tracked/committed" approach to really break my workflow. I have a lot of temporary uncommitted files, which are not ignored or excluded. Some may eventually be committed but most won't. Being then forced to commit these (but only some due to file size) just gets in the way and impedes things like cross branch debugging A checkout is a working space aft…

If you do want to solve this, here's two thoughts on how you can deal with it. First: don't try to edit jj changes. Always work on a new change and then squash that in to the parent. You think of that top level change as your working space. From there, the simplest way is to just always use 'jj commit -i' and 'jj squash -i' to create change ids with your work. Then if you want to have your changes move around with yo…

could you tell which UI tool is that where you can drag commits visually?
Post reply on HN