I'm glad that helped you!

It seems to work correctly if you include the last two lines in the first commit.

    jj-workshop on  HEAD (2cab0f1) [!]
    > jj
    @  unwquwxk samfredrickson@gmail.com 2025-07-29 18:47:18 f7db7c8a
    │  Part 2 first
    ○  wskswvnt samfredrickson@gmail.com 2025-07-29 18:47:13 git_head() 2cab0f16
    │  Part 2 second
    ◆  pnxpmvpz jkoppel@users.noreply.github.com 2025-07-27 21:54:50 main 4d04bcef
    │  Update README.md with link to JJ homepage
    ~
    
    jj-workshop on  HEAD (2cab0f1) [!]
    > jj show w --git
    Commit ID: 2cab0f167c64cea1d23407e12196fa6d1b8aab25
    Change ID: wskswvntlvtwzqutoowyqltsouklzmqr
    Author   : Sam Fredrickson <samfredrickson@gmail.com> (2025-07-29 18:34:52)
    Committer: Sam Fredrickson <samfredrickson@gmail.com> (2025-07-29 18:47:13)
    
        Part 2 second
    
    diff --git a/part1/foo.txt b/part1/foo.txt
    index 067f76475a..56c99c9cc3 100644
    --- a/part1/foo.txt
    +++ b/part1/foo.txt
    @@ -6,5 +6,5 @@
    
     * The best operating system is ______
     * The best text editor is ______
    -* The best kind of phone is _______
    -* The best superhero is ___________
    +* The best kind of phone is nothing
    +* The best superhero is nobody
    
    jj-workshop on  HEAD (2cab0f1) [!]
    > jj show u --git
    Commit ID: f7db7c8a5f37df8c29e08a6697ca6cd59c2313c4
    Change ID: unwquwxklkprlqoksmxzvoumspnmnknk
    Author   : Sam Fredrickson <samfredrickson@gmail.com> (2025-07-29 18:34:52)
    Committer: Sam Fredrickson <samfredrickson@gmail.com> (2025-07-29 18:47:18)
    
        Part 2 first
    
    diff --git a/part1/foo.txt b/part1/foo.txt
    index 56c99c9cc3..f48ae9b3f9 100644
    --- a/part1/foo.txt
    +++ b/part1/foo.txt
    @@ -4,7 +4,7 @@
    
     Maybe fill this out?
    
    -* The best operating system is ______
    -* The best text editor is ______
    +* The best operating system is Linux
    +* The best text editor is neovim
     * The best kind of phone is nothing
     * The best superhero is nobody

Wow, good catch! I had not noticed. I don't know if there is a fix for this. It seems to be a fundamental issue of the delete-and-add way of representing change hunks.

Creator here. Done.

Haven’t reviewed the material, but compatible is a weak word - jj is also compatible with a plain filesystem. The point is that it makes some workflows easy and accessible which are hard and cumbersome in git, so they become the new normal instead of things to avoid.

Every jj action is translated to a git action, but the git protocol is used only as a low level filesystem underneath, completely abstracted away. Akin to how C abstracts assembly as far I understand. No need to know assembly to use C.

You'd only really learn anything if you know nothing. The underlying git is largely invisible, and the workflows are vastly different - for the better.

It is constantly making new git commits any time you use a jj command. (I even have it set up to use watchman to create commits any time any file changes - this is unimportant for this discussion). But the commits are completely hidden - we instead interact with jj "changes", which are more like a constantly evolving, auto-adding, auto-committing, stash-free, movable git commit.

Git branches are even a 2nd class citizen. We can create endless "branches" by adding new changes on top of any existing change, and then merge that with an arbitrary amount of other changes by specifying them when creating a new change. We can also rebase/move changes around all over the place, and the changes get automatically propagated through any descendents.

We can also split and squash commits very easily, and even do so on a granular level - easily and interactively select lines or sections of changed code within one change to be split or squashed into a different change. This allows you to just work, and then tidy the history up later when you have a clue.

Conflicts that arise from merge/rebase/split/squash/etc do not require immediate intervention - fix them when you want to, and the fix will also propagate through. You can use jj resolve to open the conflicts in your merge conflict editor of choice (I use vs code).

We use git branches when we apply/update a jj bookmark to any change. This essentially creates/changes a git branch, which can then be pushed to Github. When bookmarks are pushed, the ancestor changes become "immutable" by default, which prevents things like editing, rebasing etc, so as to facilitate collaboration. But it can be override, and I presume it does things like a force push for you.

One thing to note is that your jj "branches" etc are not shared as it just stays local. You could, in theory, sync your .jj folder remotely, but I don't see that being particularly feasible unless it's just to sync with another device for your own use (or back it up in case of data loss). It's really just a local interface for individual use, and collaboration still happens via git branches and pull requests. If you were to lose your jj folder, you could clone the git repo again and you'd just start with the existing git branches etc.

I'll mention one particularly powerful/useful jj workflow - the megamerge. There's a few detailed articles out there if you search for it, and they've been discussed on hn as well (I'm on phone so can't be bothered). It allows you to merge numerous feature "branches" (again, jj branches, which are optionally also git branches if you use bookmarks) into a new branch, which lets you easily work on top of the combined functionality of various branches that are in progress. You can then interactive squash changes into their respective feature branches prior to the empty megamerge commit/change. There's also jj absorb, which does this interactive squash in a sort of magical, automatic way (though I find that sometimes it just doesn't do anything)

There's so much more to say about it, but overall you just don't need to think about git at all and instead just think about your code, and then tidy up the history etc as-needed, without much cognitive overhead or friction.

This is all made even easier by the absolutely fantastic https://github.com/idursun/jjui TUI. It's largely "just" a wrapper with shortcuts over jj commands and their resulting output. But it makes what's already simple absolutely seamless.

I hope this helps. Jj and jjui are absolutely beautiful. Ignore all the luddites who try to say "if it's just git under the hood, then I'll just keep using that myself, thank you very much".

I never intend to "raw dog" (as the kids say) git again. I do use some git mechanisms in vscode though - merge conflict resolution, diff visualization (it shows whatever has changed in the current jj change)

I found it pretty simple to get started with, but I also have a mercurial background, which I think is more closely aligned with jj.

The point of jj is to improve on the git interface. It's kind of weird to imply that jj's purpose is a drawback. I don't want git to stay git. Nor do I want SAAS solving stacked PRs for me, "free option" or not.

jj is explicitly not for teams - there's no way to share jj-proprietary stuff between checkouts of a repo, because it's a frontend for interacting with a git repo.