It turns out the snapshot model is a perfect fit for AI-assisted development. I can iterate freely without thinking about commits or worrying about saving known-good versions.
You can just mess around and make it presentable later, which Git never really let you do nicely.
Plus there’s essentially zero learning curve, since all the models know how to use JJ really well.
While I hate to engage in speculation, tell spooky stories, or screech at people about the evil CLA you have to sign in order to contribute, my personal opinion is that if Google were ever to start throwing their weight around, the project would be forked in short order and development would continue as normal – it has momentum, plenty of non-Google contributors, and a community. It's also not a product per se, though as we're about to find out, you can certainly build products on top of it – that probably makes it less likely for its current home to suddenly become proprietorial about it.
(hi Andy!)
There's some legal annoyances around e.g. CLA which was a result of being a side project of Google originally. Hopefully we'll move through that in due time. But realistically it's a much larger project at this point and has grown up a lot, it's not Martin's side project anymore.
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "if command -v jj >/dev/null && jj root >/dev/null 2>&1; then if ! jj status >/dev/null 2>&1; then echo 'WARNING: failed to snapshot jj repository, tell user to fix'; fi; fi"
}
]
}
],
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "if command -v jj >/dev/null && jj root >/dev/null 2>&1; then if ! jj status >/dev/null 2>&1; then echo 'WARNING: failed to snapshot jj repository, tell user to fix'; fi; fi"
}
]
},
I have all of them run `jj status`, because jj snapshots the working copy every time it's invoked.
You can have Claude write the hooks, but mine is:
`[[ -d .jj ]] && jj status >/dev/null 2>&1; exit 0`
You could also turn on watchman and have this property on every save of a file and not even need to worry about hooks.
I'm surprised to read that, because that's how I've always used Git (and GitHub).
That's what I've understood to be good practice with Git, and it was liberating compared with what came before. One of the nicest things about Git is you can throw things in locally without worrying about how it looks, and make it presentable later.
Citation needed. You split the commit anyway you like, e.g. with the mouse or using cursor movements or by duplicating and deleting lines. Then you move it with the mouse or cursor or whatever and squash it into the other commit. Maybe some people never intend to do it, but then these probably also don't want to learn JJ. I guess this is more of a selection bias, that these that care about history editing are also more likely to learn another VCS on their own.
If you ever tried to have multiple WIP features merged in a Git working copy, I have a great news — with jujutsu complexity of the workflow increases linearly over the number of branches, if ever: it's almost trivial. Otherwise I very much encourage you to try — in and of itself the workflow is extremely effective, it's just Git makes it complex af.
1. Use "git rebase -i commitid^" (or branch point, tag etc), ideally with editor set to Magit, set that commit to "edit" (single key 'e' in Magit) and let the rebase continue, do "git reset -p HEAD^" and select the hunks you want to remove from the first commit, "git commit --amend", then "git commit -a" (add -c if useful, e.g. to copy author and date from the previous one). or to keep the author date), then "git rebase --continue" to finish.
2. Same, but use "git reset HEAD^" (add -N if useful), then "git add -p" to select the hunks you do want to include in the first commit.
Afterwards you can do the "git rebase -i" command again if you want to reorder those commits, move them relative to other commits, or move the split-out hunks into another existing commit (use the 'f' fixup or 's' squash rebase options).
After doing this a few times and learning what the commands actually do, it starts to feel comfortable. And of course, you don't have to run those exact commands or type them out, it's just a raw, git-level view. "git rebase -i" and "git add -p" / "git reset -p" are really useful for reorganising commit hunks.
On an unrelated note, I use @~ instead of @^, because I think of moving up down the ancestry, not sideways, e.g. I'm more likely to want to change it to an older/newer commit, than I am to want to change the second parent instead. I don't get why most tutorials show it with @^, because you do focus on the commit being an ancestor, not precisely being the direct first parent, although of course for the first-level first parent, it amounts to the same.
https://www.felesatra.moe/blog/2024/12/23/jj-is-great-for-th...
I liked its features better, but chose git, and that was the correct decision.
For your use-case, mercurial has had a `largefiles`² extension for a very long time (long before git-lfs).
> I liked its features better, but chose git, and that was the correct decision.
Anyhow, my personal story with git is that I bought into the hype and social effects without really challenging my assumptions ("it must be the best, everyone says so"), until I got very fed-up with its obnoxious UI, and someone on IRC told me "ehh, give hg a shot". Nowadays, I mostly interact with git repos through hg-git and jj.
¹: https://www.kernel.org/doc/ols/2006/ols2006v2-pages-91-98.pd...
jj is very non-modal, that is, it doesn't tend to have a lot of state that commands rely on. As an example of what I mean, because jj does not have a staging area, everything is already committed, which makes it very easy to say, move to a different commit: you don't need to stash your working copy, as jj has already stashed it for you. Similarly, due to the auto-rebase behavior, you can be working in one part of the tree, realize something somewhere else should be moved, and go rebase that without even moving to it at all!
As a small example: say I'm working on something, and I find a typo. I want to send that typo in as a PR, but I don't want to do it as part of my work. I can do that with:
1. make the change in my current working copy (@)
2. jj split -o trunk (selecting the typo contents to split off the typo fix into a new change on top of (hence -o) trunk)
3. jj log (go check out what the change id of that change is
4. jj git push -c <change id I found in 3>
No need to even move my own HEAD (in git terms), just knock it out inline in a few steps while I'm working.
Now, as for magit, I don't use it, and I know that those that do love it and it does make some of this stuff easier. But not everyone can use magit. And there are "magit, but jj" projects as well, but I can't speak to them or which is best at the moment.
You can definitely use git as a backend for building such a system, but some extra tooling is necessary.
That way you get the best of both worlds. The buggy code is still there in case it's needed but it's not in the main branch
Is it? There’s the stash for storing patches, the index for storing good hunks, branching for trying out different experiments. You can even use worktree if you want separate working directory especially when there will be changes in the untracked files.
Git has a lot of tooling for dealing with changes, directly or at the meta layer.
I will admit, I didn't know jj but I wanted snapshots so I used it, so then when AI made some changes and kept on going and I wanted to go back to a particular change and I used ai to do that. It was actually really frustrating. To the point that I think I accidentally lost one of the good files within the project and I had to settle on good-enough which I had to try to get for hours to that particular point.
My point feels like I should either learn jj properly to use it or to at this point, just ask AI agents to git commit. Another point but I was using ghostty and I had accidentally clicked on the title bar and somehow moved the folder to desktop, I wasn't thinking the most accurately and I just decided to delete it thinking that it must have copied it rather than moved it. (Also dear ghostty why do you make it so easy to move folders, it isn't the best of features and can lead to some honest errors)
My face when I realized that I have deleted the project:
Anyhow decided to restore it with ~/Trash but afterwards realized that the .git/.jj history is removed because it deletes hidden folders (from my understanding) so I definitely lost that good snapshot. I do have the binary of the app which worked good but not the source code of it which is a bit frustrating
These were all just an idea of prototyping/checking how far I can move things with AI. Yeah so my experience for that project has been that I could've even learnt a new language (Odin) and the raylib project to fix that one specific bug in lower time than AI which simply is unable to fix the bug without blowing the whole project in foot.
I think the takeaway is to have good backups man. I mean I was being reckless in this project because I had nothing to lose and was just experimenting but there have been cases where people have lost databases in prod. So even backups should be essential if you find any source code which is good to be honest.
I am sure you guys must have lost some source code accidentally which you have worked upon, would love to hear some horror stories to hopefully know that I haven't been the only one who has done some mistake and to also learn something new from these stories. (I am atleast happy in the sense that I learnt the lesson from just an tinkering thing and not something truly prod)
Jujutsu has changed how I work with git. Switching tasks is just "jj edit <change>" or "JJ new <change>". The only thing it can't do properly is git worktrees (it doesn't replicate the .git dir to the worktrees, breaking tooling that relies on git) but there is a (old) issue relating to it. Not sure on the priority, though.
Anyway, YMMV, but I love it.
When I'm using agents to code, I don't want to have to stop what I'm doing and commit known-good state to the repo every few minutes.
jj just snapshots everything automatically, so I know I've captured that state, and I can look back and curate it all after the fact.
It's like the shift from manually saving Word documents to autosave, but instead of forcing it with git, I can use JJ which has been intentionally designed for that workflow.
Vibecoding moto.