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

11–20 of 552 posts

Re: Jujutsu for busy devs

#11

Post by stouset »

jackblemming wrote: post #2

I must be getting old because I really don’t think git needs a simplified model. But hey, if people find value from this, more power to them. The blog is well written too.

It’s not just that it’s simpler, it’s that the primitives and interaction model are also strictly more powerful. A ton of extremely useful workflows that are an utter pain in the ass with git are absolutely trivial with jj.

One example is a series of dependent PRs. This is excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change. It’s trivial in jj: you either fix the revision directly or you insert a new revision inbetween. The subsequent revisions are updated automatically. You don’t even have to think.

Another is splitting work into parallel branches. So often when I’m working on one area I end up making unrelated tweaks and improvements as I go. Pulling these out into their own branches is painful in git, so people just make omnibus branches that include a handful of unrelated work alongside the main task. In jj it’s basically zero work to split out the unrelated stuff onto a new branch off main, and it doesn’t require you to task-switch to a new branch. So I end up making lots of one-line PRs that are trivial to review whenever I’m doing deeper work.

Re: Jujutsu for busy devs

#12

Post by _bent »

I've been using jj for two weeks now and it's kinda exciting, because for the first time I'm comfortable with using version control just via the command line. With Git I always had to use a GUI (preferably Git Graph in VSCode) and launch all operations by right clicking items, but jj was simple and consistent enough that I could just start using it after reading Steve Klabniks tutorial.

The thing I'm running into right now is that I should really learn the revset language, so that I don't have to constantly copy paste ids from jj log

Re: Jujutsu for busy devs

#13

Post by rtpg »

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…

I usually work, then do `jj split` to review changes I want to make commits to. This generally makes the workflow look like `git add -p`.

A decent mental model is that the top-most commit isn't generally going to get pushed up anywhere. It's like your working copy but also you get stashing "for free" (change back to main to make a new commit? All the WIP stuff stays on that branch instead of being carried over to main!)

Re: Jujutsu for busy devs

#14

Post by zamalek »

I've been using jj for a few weeks, and recently made an auto-commit-message script for it[1]. Just today I started working in an old git repo and thought that I should port the script to git. It turns out that jj made the script trivial because of immutable commits, and mt script would need to automatically do that with git: I use a rebase/amend/clean history workflow at work, so I would need the script to determine when to commit or when to amend. It's obviously possible, but I don't want to expend the effort - I just re-cloned it with jj.

It's amazing how quickly I forgot about the commit vs. amend papercut.

[1]: https://codeberg.org/jcdickinson/nix/src/branch/main/home/co...

Re: Jujutsu for busy devs

#15

Post by arp242 »

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 don't especially like git. I stuck with mercurial for a long time.

But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough.

It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

Re: Jujutsu for busy devs

#16

Post by krackers »

stouset wrote: post #11
jackblemming wrote: post #2

I must be getting old because I really don’t think git needs a simplified model. But hey, if people find value from this, more power to them. The blog is well written too.

It’s not just that it’s simpler, it’s that the primitives and interaction model are also strictly more powerful. A ton of extremely useful workflows that are an utter pain in the ass with git are absolutely trivial with jj. One example is a series of dependent PRs. This is excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change. It’s trivial in j…

>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.

Re: Jujutsu for busy devs

#17

Post by ethan_smith »

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…

[flagged]

Re: Jujutsu for busy devs

#18

Post by sieve »

JJ is brilliant.

I reluctantly moved to git from mercurial when host-after-host dropped mercurial support. git is a user-hostile POS that I never got used to. A thousand needless complications including nightmare merges, and an inscrutable command interface.

JJ eliminates all the git bullshit. Some incredible features:

* Merges never fail as conflicts are a first class feature. You can come back and resolve them at any time.

* You can reset the state of the repo to any particular point in history as JJ maintains a complete operations history.

* You can insert new changes anywhere and deal with the repercussions at leisure.

I started with Steve's tutorial but found it a bit wordy. So I used Gemini to produce a simple guide for me with: "You are an expert at DVCS systems like JJ. Act as my guide for the system and answer my questions with simple cookbook-style recipes."

I have been using JJ for a month and am never going back to git. It is such a pleasure to work with a DVCS that you don't have to fight at every turn.

Re: Jujutsu for busy devs

#19

Post by sunshowers »

krackers wrote: post #16
stouset wrote: post #11

Earlier quoted context omitted.

It’s not just that it’s simpler, it’s that the primitives and interaction model are also strictly more powerful. A ton of extremely useful workflows that are an utter pain in the ass with git are absolutely trivial with jj. One example is a series of dependent PRs. This is excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change. It’s trivial in j…

>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.

git rebase -i is a much worse experience than jj's autorebasing of descendants. For example, with git rebase -i you can't decide to do something else in the middle of the rebase — you're in that state until the rebase is completed or abandoned.

Merge conflicts are also significantly better with jj because they don't interrupt the rest of your flow.

And most importantly, the two features work together to create something greater than the sum of its parts. See my testimonial (first one) at https://jj-vcs.github.io/jj/latest/testimonials/#what-the-us...

Re: Jujutsu for busy devs

#20

Post by sunshowers »

arp242 wrote: post #15
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 don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

I think jj just uses the 4 bit (16 color) terminal palette, so if a color is unreadable, you can update your terminal theme accordingly.
Post reply on HN