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

Jujutsu for busy devs

maddie.wtf

Post reply on HN
Print view View original

141–150 of 552 posts

Re: Jujutsu for busy devs

#141

Post by alwillis »

Filligree wrote: post #54
ants_everywhere wrote: post #49

I'm confused what this is? Is it just a git frontend for people who are confused by git? It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Some of the design decisions are also not great. Working copy as commit means you have no quality control. T…

> It says it abstracts the backend, but it's not clear how something so git-influenced will have abstractions that work with something like a centralized system like Perforce or Piper that has auto-increment numeric commits. Its Piper backend honestly works better than the Git backend. Which isn't a knock on the Git backend, but the impedance mismatch is worse there. > Some of the design decisions are also not great.…

> Jujutsu also has a notion of immutable commits, by default meaning (roughly) commits which have been pushed upstream.

This makes sense to me as a longtime Mercurial user. In short, by default, when you push a commit, it becomes public and therefore immutable [1].

Other awesome Mercurial features that appear in JJ are revsets [2], filesets [3] and templates [4]. Looking forward to giving JJ a try.

[1]: https://wiki.mercurial-scm.org/ChangesetEvolution

[2]: https://jj-vcs.github.io/jj/latest/revsets/

[3]: https://jj-vcs.github.io/jj/latest/filesets/

[4]: https://jj-vcs.github.io/jj/latest/templates/

Re: Jujutsu for busy devs

#142

Post by stouset »

xelxebar wrote: post #136
stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

It's certainly a solid improvement in the space of VCS UI, but beware that jj has some current limitations which might prohibit switching, especially for the git power users. Lack of gitattributes support precludes git-crypt and git-lfs usage or anything that needs filters; line ending settings will get ignored, making Windows interop a little less smooth; etc. Also note that auxillary tooling, such as git-annex and…

These are all really excellent points, and well worth calling out.

Re: Jujutsu for busy devs

#143

Post by palata »

stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

> For anyone who's debating whether or not jj is worth learning

I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day.

I can totally imagine that some people spend their day manipulating repos with git, and jj is better for them. But that's not my case, and git is already everywhere.

To me it sounds like telling me: "You HAVE TO move to bim, the better vim. It's very similar to vim, but different enough that you have to learn new stuff. But you will be infinitely more productive: when you start bim, you're already in edit mode, so you don't have to type i! And the auto-complete in Julia is objectively a lot better in bim!".

Sure, but typing "i" a few times more is really not a concern for me, and I don't use Julia. But if it's better for you, please enjoy bim!

Re: Jujutsu for busy devs

#144

Post by windward »

sngz wrote: post #139
stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

I always go back to using mercurial for personal projects. Better than both

'Doesn't use Mercurial' was top of my requirements list last time I left a job that did use it.

Re: Jujutsu for busy devs

#145

Post by palata »

stouset wrote: post #9
Lyngbakr wrote: post #5

I feel pretty dense, because I still struggle to get my head around automatically adding changes to a revision. Sometimes, I'll make a change locally to a file that I'll use during the development process that I have no intention of committing. With regular git, I never stage that file so there's no danger of accidentally pushing my change to the remote repo, but it seems with jj I'll need to somehow unstage that cha…

In jj you tend to use `jj split` to break changes apart. The selected bits become the first revision, the remaining bits become the second revision. I tend to do a bunch of work then split into small, bite-sized revisions. Often I split something out to a parallel revision (e.g., a separate branch) if it’s an independent thread of work like a bugfix elsewhere or a documentation fix. This is an obvious one-liner in jj…

I feel like I already lost more time reading this than jj would make me win if I switched :-).

Re: Jujutsu for busy devs

#146

Post by stouset »

fouc wrote: post #92

Lately I've been hearing more people are getting into jj because of how much easier it is to keep track of the code generated with tools like cursor or claude code.

Yes!

I have found it incredibly helpful when using an agent. It's a great case for the "staging-area" style workflow. I `jj new` an empty revision where the LLM can go hog-wild. When I'm generally happy with the LLM's work, I make a new revision. Then I ask it to make some improvements. Sometimes I have to discard those. No problem, I just `jj abandon` the whole thing. Sometimes I like a few pieces; I `jj squash -i` those into the parent revision with the bulk of the work and abandon the rest. And then I repeat until I'm happy with the overall output.

It's also super useful when I need to go fix something in an earlier (but still unmerged) revision. `jj new {id}` creates a new revision whose parent is the older change, even if it already has children. Again, I let the agent loose. When I'm happy, I `jj squash -i` what I want and the fixes are not only incorporated back into the parent but then propagated automatically down through the rest of its children through automatic rebasing.

Re: Jujutsu for busy devs

#147

Post by ramon156 »

kadhirvelm wrote: post #91

I’ve had a lot of success using https://graphite.dev/ . Been pretty easy to pick up and slots right into our usual GitHub workflow. I end up using the vscode extension to manage it. Anyone have opinions how jujutsu compares?

Isn't graphite a pr review tool that still uses git?

Re: Jujutsu for busy devs

#148

Post by stouset »

wredcoll wrote: post #107
steveklabnik wrote: post #70

Earlier quoted context omitted.

> I'm confused what this is? jj is a version control system. It is backend-agnostic. The most common backend is a git one, because git is so popular. This allows you to use jj on a git repository, allowing for individuals to adopt it without forcing their teammates to. > Is it just a git frontend for people who are confused by git? I used git since before github existed. I considered myself a git lover before I found…

I want to appreciate this cool-sounding new tool, but everything you've said sounds exactly the same as using git rebase, what am I missing?

Git rebase is, frankly, a massive pain in the ass. It's worth doing if you care about it. I used a rebase-heavy workflow for a decade and a half. But having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks. And it sucks even worse when you screw up the conflict resolution halfway through and have to start over from scratch.

Rebases also don't play nicely with stacked branches. Branches based off your original changes don't get rewritten to be on top of the rebased change, so now multiple rebases are in your future.

It turns out that basically none of the rebase friction most people experience is necessary in practice. Rebases can be automatic, implicit, and conflicts can be fixed at your leisure and in whatever order that you feel is best.

jj also has a ton of other powers, but you asked about rebase :)

Re: Jujutsu for busy devs

#149

Post by palata »

Filligree wrote: post #57
doritosfan84 wrote: post #3

I’ve been trying unsuccessfully to convert my team to jujutsu. I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. Something like the elevator pitch here but expanded on without the depth of Steve’s tutorial. Maybe what I need to do is do a demo so people can see and ask questions.

> I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. What I find isn't that common git operations are easier in jujutsu. They're not; sometimes they're slightly harder, due to the impedance mismatch with the git backend. Rather, what git makes easier are operations that are next to impossible — or at least highly inconveni…

I do understand that point, but to me it sounds like "you should use jj because it's a lot better at solving problems you don't have".

If there are really common use-cases where git is annoying and jj is great, it shouldn't be that hard to explain, should it? If you can say "remember how in the last few days you struggled with this? Jujutsu solves it", then I'm happy to try.

If your argument starts with "imagine you are in a team that looks like X (but your team does not), with a project that looks like Y (but your project does not), and now imagine that you need to do this thing that you have never done before...", then maybe I actually don't need jj?

Re: Jujutsu for busy devs

#150

Post by windward »

stouset wrote: post #22
krackers wrote: post #16

Earlier quoted context omitted.

>you have to manually rebase every subsequent change What do you mean by this? You can do an interactive rebase in git as well. The real issue is non-trivial merge conflicts which is going to be an issue no matter you use.

Let's say I have five commits in a row ready to go, but they should be reviewed and merged one-by-one. Upon review, I need to make a change to the first commit. How much work do you think this would be in git? How much of a pain in the ass do you think it would be if a later change conflicted with this earlier change? It is essentially zero work in jj. I `jj edit` the revision in question, make the change, and `jj pu…

No work, I set `rebase.updateRefs = true` years ago.
Post reply on HN