What would be the gotchas of doing this? I just spent some time looking into it and it looks ideal for my workflow, but I’d never heard of jj before right now. As far as I can tell the problems would be:
1. Worse-for-humans PR history (I currently use this for major feature checkpoints and human-involved sanity checks and review)
2. Maybe some tooling issues with IDEs? Looks like it’s all there, but maybe getting it set up so that the agents aren’t committing every little thought they have might be a bit finicky? I use VS Code if anyone has a workflow recommendation there.
JJ stacked changes are just a chain of git commits. To jj, a branch is just a pointer to a commit, like git. Code review is no different to whatever you normally do for git. Push to your review system and review commit by commit Gerrit style, or as a single unit, or as stacked PR (I have not done this however as I don't use GitHub any more).
git worktrees are a horrible misfeature; it's better to just clone multiple times (which you can do locally---space is saved by use of hard links!)
So that is to say, we clone some remote upstream down to /path/A. Then we can clone file:///path/A to /path/B locally. Both A and B are fully fleded git repos; no monkeying around with worktrees. The objects are shared between them with hard links. You can edit B/.gitconfig to point it to have the same upstream as A for pushing.
Unlike worktrees, you can blow away a repo with "rm -rf", and not worry that you are pulling the rug from under something which depends on it. If I have several trees, A, B, C, one of which is the parent, while the other are worktrees, removing any one of them randomly is Russian roulette: if we do "rm -rf B" and that happens to be the parent repo, worktrees A and C are no longer functional and need to be recovered. If A, B, and C are independent clones (even with objects hardlinked among themselves), this isn't a problem.
You're right about everything you said, but there is a flip side: with work trees you can:
1. find/list all related "clones" of the repo
2. Ensure that the same branch is not being worked on in different checkouts (which is useful if you do rebases as part of your workflow)
Worktrees force you distinguish the "main" repo from the swarm of checkouts, and if you locate or name directories with a rule you can always tell which are which.
For my own use, I built a little helper to create, list and destroy worktrees that fit in my workflow with Claude code:
What you described sounds like this: https://github.com/GenseeAI/gensee-crate. It offers whole workspace fork and merge. But the merge is still somewhat cumbersome and require manual overseeing.
One thing I'm wondering: have you tried this on a team with multiple humans as well, or is it mainly optimized for a single developer coordinating a bunch of Claude Code agents?
I just built something pretty much in the same vein of this with Claude over the past 2 months. It's a custom deployment system that uses work trees and each work tree has to to run end-to-end tests (Playright, Supabase, Astro) and other tests and create a stamp based on the contents of the entire tree. And then if another work tree has the same digest that matches the stamp then it can bypass the tests. So nothing can land on main without tests passing. Which is all in in enforced with a pre-push hook that checks the digest.
Then once it's on main it is deployed to Dev and then from there it can be promoted to prod.
I like the idea of just having one branch and the work trees funnel into it.
But definitely going to have my setup analyze this and see what can be improved with it or if I should just throw out mine and use that one.
idea looks nice, but can you share what's your workflow to push 90 commits/day?
I understand each commit might have different size, but I am guessing your commits == Pull Request (because you need this constant merge queue to rebase, merge, test) and each are around 40-80 lines of code (additions and removals), and you are probably not reviewing the code because at this rate even if one commit takes 2 minutes to review we are talking about 3 hours of non stop code review.
if you are not reviewing each code, probably your commits are small items and 10-20 of them are a part of single PR, then how do you sustain working across multiple projects?
I have CI set up so that I can just let that handle builds and exclusive locks for me, but there are particular limitations (network connectivity is mandatory). I did this because I wanted to avoid something like you built, which theoretically can't scale as well as a dev box (much easier to extend deploy environments versus my local machine). I can see that you are working within resource constraints though which is admirable :)
A decent idea, however it seems to me a good chunk of it is because of git limitations. Have you looked jj?
I'm having a much better time with jj and a workspace per subagent than I was with git and worktrees.
It's still useful to have the CI gating on updating the master branch pointer, but you largely stop working with branches once you switch to jj.
What would be the gotchas of doing this? I just spent some time looking into it and it looks ideal for my workflow, but I’d never heard of jj before right now. As far as I can tell the problems would be:
1. Worse-for-humans PR history (I currently use this for major feature checkpoints and human-involved sanity checks and review)
2. Maybe some tooling issues with IDEs? Looks like it’s all there, but maybe getting it set up so that the agents aren’t committing every little thought they have might be a bit finicky? I use VS Code if anyone has a workflow recommendation there.
JJ stacked changes are just a chain of git commits. To jj, a branch is just a pointer to a commit, like git. Code review is no different to whatever you normally do for git. Push to your review system and review commit by commit Gerrit style, or as a single unit, or as stacked PR (I have not done this however as I don't use GitHub any more).
git worktrees are a horrible misfeature; it's better to just clone multiple times (which you can do locally---space is saved by use of hard links!)
So that is to say, we clone some remote upstream down to /path/A. Then we can clone file:///path/A to /path/B locally. Both A and B are fully fleded git repos; no monkeying around with worktrees. The objects are shared between them with hard links. You can edit B/.gitconfig to point it to have the same upstream as A for pushing.
Unlike worktrees, you can blow away a repo with "rm -rf", and not worry that you are pulling the rug from under something which depends on it. If I have several trees, A, B, C, one of which is the parent, while the other are worktrees, removing any one of them randomly is Russian roulette: if we do "rm -rf B" and that happens to be the parent repo, worktrees A and C are no longer functional and need to be recovered. If A, B, and C are independent clones (even with objects hardlinked among themselves), this isn't a problem.
You're right about everything you said, but there is a flip side: with work trees you can:
1. find/list all related "clones" of the repo
2. Ensure that the same branch is not being worked on in different checkouts (which is useful if you do rebases as part of your workflow)
Worktrees force you distinguish the "main" repo from the swarm of checkouts, and if you locate or name directories with a rule you can always tell which are which.
For my own use, I built a little helper to create, list and destroy worktrees that fit in my workflow with Claude code:
https://github.com/mkmik/ccwt
What you described sounds like this: https://github.com/GenseeAI/gensee-crate. It offers whole workspace fork and merge. But the merge is still somewhat cumbersome and require manual overseeing.
Giving up branches is the dream. This feels like the nudge I needed to give jj a proper go. Thank you.
One thing I'm wondering: have you tried this on a team with multiple humans as well, or is it mainly optimized for a single developer coordinating a bunch of Claude Code agents?
Definitely going to look into this!
I just built something pretty much in the same vein of this with Claude over the past 2 months. It's a custom deployment system that uses work trees and each work tree has to to run end-to-end tests (Playright, Supabase, Astro) and other tests and create a stamp based on the contents of the entire tree. And then if another work tree has the same digest that matches the stamp then it can bypass the tests. So nothing can land on main without tests passing. Which is all in in enforced with a pre-push hook that checks the digest.
Then once it's on main it is deployed to Dev and then from there it can be promoted to prod.
I like the idea of just having one branch and the work trees funnel into it.
But definitely going to have my setup analyze this and see what can be improved with it or if I should just throw out mine and use that one.
idea looks nice, but can you share what's your workflow to push 90 commits/day?
I understand each commit might have different size, but I am guessing your commits == Pull Request (because you need this constant merge queue to rebase, merge, test) and each are around 40-80 lines of code (additions and removals), and you are probably not reviewing the code because at this rate even if one commit takes 2 minutes to review we are talking about 3 hours of non stop code review.
if you are not reviewing each code, probably your commits are small items and 10-20 of them are a part of single PR, then how do you sustain working across multiple projects?
SelfCI: https://radicle.network/nodes/radicle.dpc.pw/rad:z2tDzYbAXxT... , supports git & jj
I have CI set up so that I can just let that handle builds and exclusive locks for me, but there are particular limitations (network connectivity is mandatory). I did this because I wanted to avoid something like you built, which theoretically can't scale as well as a dev box (much easier to extend deploy environments versus my local machine). I can see that you are working within resource constraints though which is admirable :)
Exactly, have to shave a few corners when your laptop doesn't even have a fan :)