Shoutout to graphite.dev that gives you a stacked workflow on top of git/github - everything actually stays git, it just auto-updates the stack of branches and manages updating the PRs accordingly + will auto-merge PRs for you once they’re ready.
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.
The one paragraph that helped jj begin to click for me was this one from Steve's Jujutsu Tutorial[0]:
> If you want to replicate git's behavior, typing an additional command after each change is done feels like overkill. But I would argue this is not the right way to use jj; as you'll see, we'll be either re-writing commits at the tip of branches, or doing multiple steps of work before updating where a branch points. In practice, it means I check the branch status before pushing code, rather than as I work. That is, the branch name tends to sit at the same change as the remote server, and when it's time to update the remote, that's when I update things locally.
That, as I interpreted it, is to mean one should begin to "forget" git in order to appreciate jj with a sense of new beginning.
Previously, I was continuously translating jj to git, and vice-versa. After reading this paragraph, I now mentally model the jj-git relationship as a kind of 3rd stage of the workflow, rather than previously assuming jj as an abstraction on top of git.
Something I ran into during exercise 2 (and from watching the solution video[0] closely I see the author did as well):
There were four consecutive changed lines in my original commit. When I split it, I selected the deletion and addition for the first two lines. In the resulting newly created commit, those two lines had been moved to below the other two lines, so the order was now 3 -> 4 -> 1 -> 2, with the second commit moving 3 and 4 back to their original places. I didn't figure out a clean way to fix this - when I edited the commit which changed lines 1 and 2 to put them back at the top, it made a conflict with the second commit which I had to repair.
Anybody know what I should have done differently to split the commit and keep the edited lines in their original places?
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.
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
12 comments
[ 3.6 ms ] story [ 42.3 ms ] threadDoes that mean that working through this will also improve your git usage? Or could be used to teach someone git workflows?
> If you want to replicate git's behavior, typing an additional command after each change is done feels like overkill. But I would argue this is not the right way to use jj; as you'll see, we'll be either re-writing commits at the tip of branches, or doing multiple steps of work before updating where a branch points. In practice, it means I check the branch status before pushing code, rather than as I work. That is, the branch name tends to sit at the same change as the remote server, and when it's time to update the remote, that's when I update things locally.
[0]: https://steveklabnik.github.io/jujutsu-tutorial/sharing-code...
(emphasis mine)
That, as I interpreted it, is to mean one should begin to "forget" git in order to appreciate jj with a sense of new beginning.
Previously, I was continuously translating jj to git, and vice-versa. After reading this paragraph, I now mentally model the jj-git relationship as a kind of 3rd stage of the workflow, rather than previously assuming jj as an abstraction on top of git.
There were four consecutive changed lines in my original commit. When I split it, I selected the deletion and addition for the first two lines. In the resulting newly created commit, those two lines had been moved to below the other two lines, so the order was now 3 -> 4 -> 1 -> 2, with the second commit moving 3 and 4 back to their original places. I didn't figure out a clean way to fix this - when I edited the commit which changed lines 1 and 2 to put them back at the top, it made a conflict with the second commit which I had to repair.
Anybody know what I should have done differently to split the commit and keep the edited lines in their original places?
[0]: https://www.loom.com/share/e3e148f07fb9420180ebb047f5ca94b3