Hacker News Reader

Comment by wsycharles0o | Hacker News Reader

I’m confused. Isn’t this exactly the same as git commands?

Many jj commands share names with git commands, yes. That doesn't always mean they do the same exact thing. There's lots that are different too.

Sounds like something ready for the mass population.

It is true that if you're looking for a finished, polished product, jj is very much not that. It's pre-1.0. Lots of things will change.

I still refuse to use anything else these days, but I can understand why someone else might not want to.

This was true of svn and git; both had command named the same as VCSs that were popular when they were introduced, but had semantics that were subtly (or not so subtly) different.

Unironically, it is. The underlying storage engine is git, which is rock-solid.

But to put it this way, I've been using jj for almost a year, and even without a 1.0 release, editor support, or mature tooling, it's still such an improvement over git, I've stopped using git 98% of the time.

> That doesn't always mean they do the same exact thing. There's lots that are different too.

That's good. Gotta keep people on their toes.

With `jj undo`, it's not a huge deal. I'm (mostly) kidding.

jj has to weigh trying to be the best VCS it can be alongside factors like "how much will this confuse someone who's used to git." Both things are important, and balancing them is a tricky process.

Take `jj commit` for example. This "does what git commit does," sorta. But also, not really? But if you're five minutes into `jj`, coming from `git`, then yeah, `jj commit` is exactly what you think it is. And that lets you be comfortable. Even though, from the `jj` perspective, it's a very bad name.

What is that one popular use case which git does really bad and jj does good ?

I am laughing. Fearless merging/rebasing/context switching? Having just one way of doing things?

Best to ask the other way around at the current JJ flaws. Which right now would be tooling support and you actually have to be on top of your .gitignore.

Virtually everything is easier. How much easier is up for debate.

Part of the issue is that everything is interlocking. Small gains in multiple places end up feeling so, so much nicer, even if they may not seem like it. So for example, the index in git is a workflow pattern in jj, not a built in feature. This means that you don't have `git reset` with `--soft` vs `--hard` vs `--mixed`: You just have `jj edit`. This decision also means `jj rebase` can be entirely in memory, which means it's fast. But that wouldn't matter if conflicts weren't a first-class concept in jj, so things like rebase always succeed and immediately. Which doesn't sound like a big deal but you find yourself being able to rebase way more often and way more easily...

It's not that git is bad. And it's not that it's bad at a specific thing. It's just that taking some of the other sides of some of the tradeoffs means that you get something that's smaller but also more powerful. And that's cool.

I think the "mega merge" plus `jj absorb` might be one of the more flashy things: https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim...

but I don't even do that. The basics are still just nicer.

So I've been hovering around jj for a while, trying to understand how it works, without suceeding in having a good mental model around it. I looked at this megamerge workflow and it's the first one that "clicked" for me (even though I'm not sure I understand the magic behind jj absorb, but I'll look into it). One thing though is that I don't quite understand how it would work in the context of a real git repo. Let's say I work on two branches, main and feature1, I'd create a [merge] commit that is has the two bookmarks as parents. But if after a fetch main has new changes, do I need to discard the current [merge] and recreate it again ? I can't find a way to just say "Update the parents so they track these bookmarks". I just tried it on a real repo, working on a change in a branch, then on a change on another branch, then adding a third branch I needed to work on that was not a parent yet, but this seems like a lot of boilerplate to always recreate my megamerge setup so I think I'm missing something

> One thing though is that I don't quite understand how it would work in the context of a real git repo.

Just to be clear, `jj` stores all of its stuff in a real git repo. I know you probably meant "using git instead of jj" but I wanted to point that out because it means that you can just go look at what it does. I will say that sometimes that can be confusing, and I'd be very careful running git commands that modify history inside that directory.

So for example, here's a simple mega merge:

     jj log
    @        oyktpwwq steve@steveklabnik.com 2025-02-12 13:25:41 79d7cf16
    ├─┬─┬─╮  (empty) (no description set)
    │ │ │ ○  qvqxlymp steve@steveklabnik.com 2025-02-12 13:25:34 9403fc75
    │ │ ├─╯  (empty) C
    │ │ ○  wrqmrkot steve@steveklabnik.com 2025-02-12 13:25:32 2df38e4e
    │ ├─╯  (empty) B
    │ ○  oluunuku steve@steveklabnik.com 2025-02-12 13:25:29 19d713aa
    ├─╯  (empty) A
    ○  vukunsxq steve@steveklabnik.com 2025-02-12 13:25:25 main git_head() d29e7411
    │  (empty) (no description set)
    ◆  zzzzzzzz root() 00000000

the first commit after the root is bookmarked as `main`, our three changes are on top of it, with a mega merge.

I've used a colocated repo, so the `.git` dir is at the top level, so we can just run `git log`:

     git log --graph --all
    *---.   commit 79d7cf16869f0f293b18ff4fa339d2d053b537c0 (refs/jj/keep/79d7cf16869f0f293b18ff4fa339d2d053b537c0)
    |\ \ \  Merge: d29e741 19d713a 2df38e4 9403fc7
    | | | | Author: Steve Klabnik <steve@steveklabnik.com>
    | | | | Date:   Wed Feb 12 13:25:41 2025 -0600
    | | | |
    | | | * commit 9403fc75d2ec85491d990c7322b0f5f8f500fa78 (refs/jj/keep/9403fc75d2ec85491d990c7322b0f5f8f500fa78)
    | | |/  Author: Steve Klabnik <steve@steveklabnik.com>
    | | |   Date:   Wed Feb 12 13:25:34 2025 -0600
    | | |
    | | |       C
    | | |
    | | * commit 2df38e4eccbd31ef70a810dd86c637cc2110912c (refs/jj/keep/2df38e4eccbd31ef70a810dd86c637cc2110912c)
    | |/  Author: Steve Klabnik <steve@steveklabnik.com>
    | |   Date:   Wed Feb 12 13:25:32 2025 -0600
    | |
    | |       B
    | |
    | * commit 19d713aab65d0e572994634b2487ce7637d6752a (refs/jj/keep/19d713aab65d0e572994634b2487ce7637d6752a)
    |/  Author: Steve Klabnik <steve@steveklabnik.com>
    |   Date:   Wed Feb 12 13:25:29 2025 -0600
    |
    |       A
    |
    * commit d29e7411f098bba0120cfd5b819b732dabcb6f73 (HEAD, refs/jj/keep/d29e7411f098bba0120cfd5b819b732dabcb6f73)
      Author: Steve Klabnik <steve@steveklabnik.com>
      Date:   Wed Feb 12 13:25:25 2025 -0600

So this is the initial state.

Let's say that we pull down our remote, and main has changed, as you've said. There is a new commit on top of it.

We can simulate this in jj. (q is valid because we have so few changes there's no others that start with q yet)

     jj new v --no-edit -m "changes from upstream"
    Created new commit trzwxsrr c8318f5f (empty) changes from upstream
    
     jj bookmark create -r t main@origin
    Created 1 bookmarks pointing to trzwxsrr c8318f5f main@origin | (empty) changes from upstream

here's our log in `jj`:

     jj log
    @        oyktpwwq steve@steveklabnik.com 2025-02-12 13:25:41 79d7cf16
    ├─┬─┬─╮  (empty) (no description set)
    │ │ │ ○  qvqxlymp steve@steveklabnik.com 2025-02-12 13:25:34 9403fc75
    │ │ ├─╯  (empty) C
    │ │ ○  wrqmrkot steve@steveklabnik.com 2025-02-12 13:25:32 2df38e4e
    │ ├─╯  (empty) B
    │ ○  oluunuku steve@steveklabnik.com 2025-02-12 13:25:29 19d713aa
    ├─╯  (empty) A
    │ ○  trzwxsrr steve@steveklabnik.com 2025-02-12 13:27:16 main@origin c8318f5f
    ├─╯  (empty) changes from upstream
    ○  vukunsxq steve@steveklabnik.com 2025-02-12 13:25:25 main git_head() d29e7411
    │  (empty) (no description set)
    ◆  zzzzzzzz root() 00000000

and in `git`:

     git log --graph --all
    * commit c8318f5fd641a9b271b67e90e7ca1c465b1a92da (refs/jj/keep/c8318f5fd641a9b271b67e90e7ca1c465b1a92da, main@origin)
    | Author: Steve Klabnik <steve@steveklabnik.com>
    | Date:   Wed Feb 12 13:27:16 2025 -0600
    |
    |     changes from upstream
    |
    | *-.   commit 79d7cf16869f0f293b18ff4fa339d2d053b537c0 (refs/jj/keep/79d7cf16869f0f293b18ff4fa339d2d053b537c0)
    |/|\ \  Merge: d29e741 19d713a 2df38e4 9403fc7
    | | | | Author: Steve Klabnik <steve@steveklabnik.com>
    | | | | Date:   Wed Feb 12 13:25:41 2025 -0600
    | | | |
    | | | * commit 9403fc75d2ec85491d990c7322b0f5f8f500fa78 (refs/jj/keep/9403fc75d2ec85491d990c7322b0f5f8f500fa78)
    | | |/  Author: Steve Klabnik <steve@steveklabnik.com>
    | | |   Date:   Wed Feb 12 13:25:34 2025 -0600
    | | |
    | | |       C
    | | |
    | | * commit 2df38e4eccbd31ef70a810dd86c637cc2110912c (refs/jj/keep/2df38e4eccbd31ef70a810dd86c637cc2110912c)
    | |/  Author: Steve Klabnik <steve@steveklabnik.com>
    | |   Date:   Wed Feb 12 13:25:32 2025 -0600
    | |
    | |       B
    | |
    | * commit 19d713aab65d0e572994634b2487ce7637d6752a (refs/jj/keep/19d713aab65d0e572994634b2487ce7637d6752a)
    |/  Author: Steve Klabnik <steve@steveklabnik.com>
    |   Date:   Wed Feb 12 13:25:29 2025 -0600
    |
    |       A
    |
    * commit d29e7411f098bba0120cfd5b819b732dabcb6f73 (HEAD, refs/jj/keep/d29e7411f098bba0120cfd5b819b732dabcb6f73, main)
      Author: Steve Klabnik <steve@steveklabnik.com>
      Date:   Wed Feb 12 13:25:25 2025 -0600

So now we get to the issue: git would want us to rebase every one of these branches individually. When we rebase A (19d713aab65d0e572994634b2487ce7637d6752a) on top of main@origin (c8318f5fd641a9b271b67e90e7ca1c465b1a92da), well: (don't do this in a real repo, since this is an example I'm okay with trashing things, I even made a copy of the repo before doing this)

     git checkout 19d713aab65d0e572994634b2487ce7637d6752a
    Previous HEAD position was d29e741
    HEAD is now at 19d713a A

     git rebase main@origin

     git log --all --graph
    * commit f397936ac0d4510682e68ab470eb81863a5c2a73 (HEAD)
    | Author: Steve Klabnik <steve@steveklabnik.com>
    | Date:   Wed Feb 12 13:25:29 2025 -0600
    |
    |     A
    |
    * commit c8318f5fd641a9b271b67e90e7ca1c465b1a92da (refs/jj/keep/c8318f5fd641a9b271b67e90e7ca1c465b1a92da, main@origin)
    | Author: Steve Klabnik <steve@steveklabnik.com>
    | Date:   Wed Feb 12 13:27:16 2025 -0600
    |
    |     changes from upstream
    |
    | *-.   commit 79d7cf16869f0f293b18ff4fa339d2d053b537c0 (refs/jj/keep/79d7cf16869f0f293b18ff4fa339d2d053b537c0)
    |/|\ \  Merge: d29e741 19d713a 2df38e4 9403fc7
    | | | | Author: Steve Klabnik <steve@steveklabnik.com>
    | | | | Date:   Wed Feb 12 13:25:41 2025 -0600
    | | | |
    | | | * commit 9403fc75d2ec85491d990c7322b0f5f8f500fa78 (refs/jj/keep/9403fc75d2ec85491d990c7322b0f5f8f500fa78)
    | | |/  Author: Steve Klabnik <steve@steveklabnik.com>
    | | |   Date:   Wed Feb 12 13:25:34 2025 -0600
    | | |
    | | |       C
    | | |
    | | * commit 2df38e4eccbd31ef70a810dd86c637cc2110912c (refs/jj/keep/2df38e4eccbd31ef70a810dd86c637cc2110912c)
    | |/  Author: Steve Klabnik <steve@steveklabnik.com>
    | |   Date:   Wed Feb 12 13:25:32 2025 -0600
    | |
    | |       B
    | |
    | * commit 19d713aab65d0e572994634b2487ce7637d6752a (refs/jj/keep/19d713aab65d0e572994634b2487ce7637d6752a)
    |/  Author: Steve Klabnik <steve@steveklabnik.com>
    |   Date:   Wed Feb 12 13:25:29 2025 -0600
    |
    |       A
    |
    * commit d29e7411f098bba0120cfd5b819b732dabcb6f73 (refs/jj/keep/d29e7411f098bba0120cfd5b819b732dabcb6f73, main)
      Author: Steve Klabnik <steve@steveklabnik.com>
      Date:   Wed Feb 12 13:25:25 2025 -0600

We only get one branch. So what we'd have to do is go back and fix up every single branch here, including our merge. And so yeah, you can do it, but it's a giant pain in the butt. And for the children, you really need --onto, so you'd end up doing something like

    $ git checkout 2df38e4eccbd31ef70a810dd86c637cc2110912c
    $ git rebase HEAD --onto f397936ac
    $ git checkout 9403fc75d2ec85491d990c7322b0f5f8f500fa78
    $ git rebase HEAD --onto <new head of branch the first rebase committed>

for every branch. HOWEVER, git has introduced --update-refs, which can automate this. But it's from 2022, and my Ubuntu is a bit old, and so I cannot actually try it out.

That allll being said, I also don't know how well --update-refs does with the mega merge commit itself.

> this seems like a lot of boilerplate to always recreate my megamerge setup so I think I'm missing something

I mean, the entire thesis here is that stuff is easier in jj than it is in git: it doesn't mean you're missing something it means that git can be a bit clunky sometimes.

> So now we get to the issue: git would want us to rebase every one of these branches individually.

> [..]

> We only get one branch. So what we'd have to do is go back and fix up every single branch here, including our merge.

Not really, sounds close to git's --rebase-merges (formerly --preserve-merges):

  git rebase --onto main@origin main 79d7cf16869f0f293b18ff4fa339d2d053b537c0 --rebase-merges

I'm guessing putting "--update-refs" on top of it would give you exactly what you want. I also have a version without it though.

Ah nice, thank you!

- Easy and robust undo.

- Intuitive, simpler (but still general and powerful) UI.

It's a bit unfortunate because most of the listed commands are indeed equivalent to Git commands. To give an example of new capabilities, in Git, you can't do the equivalent of

    jj rebase -r 'mine() & diff_contains("TODO")' -d 'heads(@::)'

in any reasonable number of commands, which will

1) find all of the commits I authored with the string `TODO` in the diff

2) extract them from their locations in the commit graph

3) rebase all non-matching descendant commits onto their nearest unaffected ancestor commits

4) find the most recent work I'm doing on the current branch (topologically, the descendant commit of the current commit which has no descendants of its own, called a "head")

5) rebase all extracted commits onto that commit, while preserving the relative topological order and moving any branches.

Furthermore, any merge conflicts produced during the process are stored for later resolution; I don't have to resolve them until I'm ready to do so. (That kind of VCS workflow is not useful for some people, but it's incredibly useful for me.)

So you're taking every single TODO commit and rebasing it on top of current? Why would we do that?

??.. wdym why, what?.

Also this is just an example, there are a lot of very complex (from the point of git) things that are trivial like that in jj.

Although if you're asking "why would we do that" then I don't even know what to tell you lol

I think it was a very valid question. I was, and still am, wondering the same thing

I guess you could question the specific example, but to me the question sounded like "why would you do rebases".

Like, for various reasons?.

The point was that it's way easier and way safer to do rebases in jj, and it straight up allows to do complex stuff like the mentioned example easily and inderstandably, idk

I might do it if the commits in my stack are mostly independent and I want to commute the ones with `TODO` to be later. This might be so that I can

- run checks on the sequence of done commits, without getting wrong/unhelpful results because of the presence of an unfinished commit in the sequence

- put the done commits up for review now

(This is predicated on certain workflows being acceptable / useful for the user, such as modifying existing commits and reordering commits.)

It's also just an example. You can swap in your favorite query into `-r` if you don't have any need for moving `TODO` commits around. Regardless, Git is not easily able to replicate most such invocations.

I previously meant to link to the jj revset docs here: https://jj-vcs.github.io/jj/v0.26.0/revsets/

Reply on news.ycombinator.com