Great tutorial, technical level and writing rhythm are just perfect (for me at least).
Feels great to read something written with care that doesn't sound like yet another Claude-generated blog post.
Here I was thinking it was a book about Jujutsu. I don't use the noncombat version but for what it's worth, this seems well written. So kudos to the author.
I've tried JJ multiple times, but always tapped out after a day. Having to work with raw SHA1 hashes is so utterly tedious and I never quite figured out how to... just use it in normal day to day work.
The book looks well done and a labor of love, but the #1 issue Git users have, merge conflicts, isn't discussed until chapter 13 (reminds me of a Neovim tutorial I read recently where "editing text" isn't until chapter 6).
> Having to work with raw SHA1 hashes is so utterly tedious
Wot? You're holding it wrong. With jj you use raw hashes far less than git.
When you start, you use bookmarks mostly because your using as alternate porcelain git and still thinking in terms of git HEAD. Later you will grow comfortable with stacks of changes, and then you will start using change-id's (not SHA1's). Much later, you will learn revset's, and create a few revset aliases of your own, and be moving around the commit tree so fast a git person looking on won't understand what's happening. Then, one day, you will be forced to move back to git, try do to something, and wonder how you every did anything with it and hate every minute you are forced to use it. That's over a year away.
I'm like 30% sure this is satirical but if it's not...
I never, during daily driving, use hashes in git, it's all branch names. If I'm using hashes it's because something went quite wrong and I'm into https://xkcd.com/1597/ territory. Why would I want to move whatever a "revset" is around commits? Doesn't that just... break the point of a commit as a confirmed set of changes?
JJ seems like a thing for people who like managing code vs writing it.
Having a read through and so far enjoying the cadence and pacing.
Just wanted to note, before I forget, that there is a typo @ https://arialdo.codeberg.page/ju-ju-tsu/preface/at-a-glance....
Impatietn —> Impatient
Great tutorial, technical level and writing rhythm are just perfect (for me at least). Feels great to read something written with care that doesn't sound like yet another Claude-generated blog post.
I'll read it, even just to read something non Claude like for a change.
Here I was thinking it was a book about Jujutsu. I don't use the noncombat version but for what it's worth, this seems well written. So kudos to the author.
I've tried JJ multiple times, but always tapped out after a day. Having to work with raw SHA1 hashes is so utterly tedious and I never quite figured out how to... just use it in normal day to day work.
The book looks well done and a labor of love, but the #1 issue Git users have, merge conflicts, isn't discussed until chapter 13 (reminds me of a Neovim tutorial I read recently where "editing text" isn't until chapter 6).
> Having to work with raw SHA1 hashes is so utterly tedious
Wot? You're holding it wrong. With jj you use raw hashes far less than git.
When you start, you use bookmarks mostly because your using as alternate porcelain git and still thinking in terms of git HEAD. Later you will grow comfortable with stacks of changes, and then you will start using change-id's (not SHA1's). Much later, you will learn revset's, and create a few revset aliases of your own, and be moving around the commit tree so fast a git person looking on won't understand what's happening. Then, one day, you will be forced to move back to git, try do to something, and wonder how you every did anything with it and hate every minute you are forced to use it. That's over a year away.
I'm like 30% sure this is satirical but if it's not...
I never, during daily driving, use hashes in git, it's all branch names. If I'm using hashes it's because something went quite wrong and I'm into https://xkcd.com/1597/ territory. Why would I want to move whatever a "revset" is around commits? Doesn't that just... break the point of a commit as a confirmed set of changes?
JJ seems like a thing for people who like managing code vs writing it.