←back to thread

Jujutsu for everyone

(jj-for-everyone.github.io)
434 points Bogdanp | 5 comments | 31 Aug 25 15:31 UTC | HN request time: 0s | source
Show context
marcuskaz ◴[31 Aug 25 16:14 UTC] No.45084298[source]▶
> Jujutsu is more powerful than Git. Despite the fact that it's easier to learn and more intuitive, it actually has loads of awesome capabilities for power users that completely leave Git in the dust.

Like? This isn't explained, I'm curious on why I would want to use it, but this is just an empty platitude, doesn't really give me a reason to try.

replies(7): >>45084316 #>>45084327 #>>45084439 #>>45084678 #>>45088571 #>>45092597 #>>45093098 #
pkulak ◴[31 Aug 25 16:51 UTC] No.45084678[source]▶
Say you start on Main, then make a new branch that you intend to be a PR someday. You make commit 1. Then another. Maybe 6 more. Now you realize that something in commit 1 should have been done differently. So, you "edit" commit 1. All the other commits automatically rebase on top and when you go back to your last commit, it's there. Same with _after_ you PR and someone notices something in commit 3. Edit it, push, and it's fixed.

You can do all that in Git, but I sure as hell never did; and my co-workers really appreciate PRs that are broken into lots of little commits that can be easily looked over, one by one.

replies(4): >>45084727 #>>45084733 #>>45084935 #>>45085106 #
adastra22 ◴[31 Aug 25 16:57 UTC] No.45084733[source]▶
I do this every day in git. “git rebase -i [hash]” fyi.
replies(1): >>45084782 #
baq ◴[31 Aug 25 17:02 UTC] No.45084782[source]▶
you think you do, but you don't; jj edit is much, much better than an edit step in a rebase - it essentially keeps rebasing while you're editing, so you can always see which changes get conflicts, then you are free to resolve them, or not, at your convenience.
replies(3): >>45084799 #>>45086057 #>>45086723 #
8n4vidtmkvmk ◴[31 Aug 25 19:07 UTC] No.45086057[source]▶
Jj edit isn't even the jj way of doing things. Should be jj new. Unless you have changes stacked after then you'd do jj new -A. And squish when you're done
replies(1): >>45086389 #
BeetleB ◴[31 Aug 25 19:43 UTC] No.45086389[source]▶
As a relatively new jj user, I'm curious. Why is the jj new -A + squash better than just a jj edit?
replies(3): >>45086416 #>>45087841 #>>45089421 #
baq ◴[31 Aug 25 19:45 UTC] No.45086416{5}[source]▶
Separation of concerns and performance; when you edit, the commit in the middle of the branch is your working copy and you’ll update the whole branch unnecessarily many times vs just once when you’re on a logical checkpoint.
replies(1): >>45088090 #
adastra22 ◴[31 Aug 25 23:39 UTC] No.45088090{6}[source]▶
Not everyone works by “logical checkpoint” commit strategy. I myself want my tree clean and commits being atomic state transitions. Otherwise git bisect (which I rely on) would break.

A lot of the jj strategies in this thread are a bit more cowboy, and I’m surprised.

replies(1): >>45089163 #
steveklabnik ◴[01 Sep 25 03:22 UTC] No.45089163{7}[source]▶
The key is to be cowboy until you’re happy with things, and then get clean, just like with git. It’s way easier to slice and dice commits with jj and so you can be sloppy at first and it’s easy to turn beautiful afterward.
replies(1): >>45089939 #
adastra22 ◴[01 Sep 25 06:14 UTC] No.45089939{8}[source]▶
That’s not how I use git, at all. I have a messy workspace with a lot of things going on simultaneously, and only selectively stage when something crosses the finish line. Sounds very difficult to do this in jj.
replies(3): >>45090278 #>>45091465 #>>45095204 #
1. steveklabnik ◴[01 Sep 25 07:12 UTC] No.45090278{9}[source]▶
Selectively staging is easier in jj. I loved git’s index, jj does it better.
replies(1): >>45094652 #
2. adastra22 ◴[01 Sep 25 17:20 UTC] No.45094652[source]▶
How? The jj documentation seems to be pretty clear about getting rid of the staging area.
replies(3): >>45094935 #>>45095953 #>>45096638 #
3. baq ◴[01 Sep 25 17:49 UTC] No.45094935[source]▶
staging isn't needed since everything including the working copy is a commit you can split, rebase, etc. without any checkin step. yes, it does make sense and yes, it works in practice - the uncommitted vs staged vs committed states are very git-specific and don't need to be special in any way. if you check in the wrong thing (note - your working copy is a commit, so by definition you can't not have wrong things checked in at times) you split it (stage and/or commit in git).
4. Human-Cabbage ◴[01 Sep 25 19:44 UTC] No.45095953[source]▶
There are a couple main ways to achieve a workflow similar to Git's staging area.

#1: Squashing

Create a revision for the feature, then create another revision atop that.

  $ jj new main -m 'feature'
  $ jj new
  $ jj
  @  trtpzvno samfredrickson@gmail.com 2025-09-01 12:32:33 9ac76a0f
  │  (empty) (no description set)
  ○  wvzltyyr samfredrickson@gmail.com 2025-09-01 12:32:31 80b2d5d0
  │  (empty) feature
  ◆  zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  $ vim
  $ jj
  @  trtpzvno samfredrickson@gmail.com 2025-09-01 12:34:50 5516c2b9
  │  (no description set)
  ○  wvzltyyr samfredrickson@gmail.com 2025-09-01 12:32:31 80b2d5d0
  │  (empty) feature
  ◆  zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~
  $ jj squash -i
  # interactively choose hunks to squash into parent
  $ jj
  @  oxqnumku samfredrickson@gmail.com 2025-09-01 12:35:48 8694aa34
  │  (empty) (no description set)
  ○  wvzltyyr samfredrickson@gmail.com 2025-09-01 12:35:48 47110bff
  │  feature
  ◆  zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~
#2: Splitting

Create a revision for the feature, then split it up retroactively.

  $ jj new main -m 'feature'
  $ jj
  @  snomlyny samfredrickson@gmail.com 2025-09-01 12:38:39 84c6ecaa
  │  (empty) feature
  ◆  zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~
  $ vim
  $ jj
  @  snomlyny samfredrickson@gmail.com 2025-09-01 12:39:51 8038bdd4
  │  feature
  ◆  zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~
  $ jj split
  # interactively choose hunks to keep, splitting the rest into a new revision
  $ jj
  @  zpnpvvzl samfredrickson@gmail.com 2025-09-01 12:41:47 5656f1c5
  │  debugging junk
  ○  snomlyny samfredrickson@gmail.com 2025-09-01 12:41:44 1d17740b
  │  feature
  ◆  zxrulorx samfredrickson@gmail.com 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~
5. steveklabnik ◴[01 Sep 25 21:11 UTC] No.45096638[source]▶
Because it’s not a distinct feature, it’s just another commit. Which means you can bring all of the usual tools for modifying commits to bear. My sibling has some details, but at the high level, that’s the idea.