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.
grim_io 2 days ago [-]
I'll read it, even just to read something non Claude like for a change.
metiscus 2 days ago [-]
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.
cguess 2 days ago [-]
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).
rstuart4133 2 days ago [-]
> 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.
cguess 2 days ago [-]
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.
rstuart4133 1 days ago [-]
> JJ seems like a thing for people who like managing code vs writing it.
No, I'm serious. jj doesn't have git commands you use regularly, like commit and add. It does them automagically. Most rebases happen that way as well. If your goal is to spend less time screwing around, typing VCS CLI commands, use jj.
But it will be less time only in the long term. In the very short term you will flounder around just like you did when you started out with git, which you used "rm -r repo; git clone ssh://../repo" to recover. (No need for that in jj, because "jj undo" works for all jj commands. Consequently unlike git no jj command can lose information.) Then you will spend months using it as alternate git porcelain. It's only after the many more months it takes to absorb its ways via osmosis that you start using it the way its makers intended.
You said you used it for a few hours. If so, you didn't get very far into the floundering stage, let alone start to work your way out of it. You need to be decidedly more persistent than that to become familiar with any new tool. Until you do, "you're holding it wrong" is a pretty accurate description of why it didn't work for you.
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
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).
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 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.
No, I'm serious. jj doesn't have git commands you use regularly, like commit and add. It does them automagically. Most rebases happen that way as well. If your goal is to spend less time screwing around, typing VCS CLI commands, use jj.
But it will be less time only in the long term. In the very short term you will flounder around just like you did when you started out with git, which you used "rm -r repo; git clone ssh://../repo" to recover. (No need for that in jj, because "jj undo" works for all jj commands. Consequently unlike git no jj command can lose information.) Then you will spend months using it as alternate git porcelain. It's only after the many more months it takes to absorb its ways via osmosis that you start using it the way its makers intended.
You said you used it for a few hours. If so, you didn't get very far into the floundering stage, let alone start to work your way out of it. You need to be decidedly more persistent than that to become familiar with any new tool. Until you do, "you're holding it wrong" is a pretty accurate description of why it didn't work for you.