[barrkel]

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.

[grahamas]

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.

[barrkel]

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).

[kazinator]

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.

[ithkuil]

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

[kazinator]

> Ensure that the same branch is not being worked on in different checkouts

worktrees ensure that the same local tracking branch is not being the basis for different trees. So when you do want to work on some independent things in parallel which share the same upstream branch, you have go through the annoyance of giving the local branches different names: master-2, master-alt, master-bug2359 ...

With multiple git repos instead of work trees, you just use the same name. All three of your repos can be on rev-3-branch: the same local name for the remote origin/rev-3-branch.

The most common example of this is multiple repos of the same upstream that are all on the default branch like master.

You can easily apply rebase workflow independently on all of them, and it's easily possible to add them to each other as remotes, to move commits sideways. If we commit something in repo A on master, and do a "git fetch A" in repo B, we can then easily "git cherry pick A/master" to get that commit into B's master.

[yiyingzhang]

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.

[funador]

Giving up branches is the dream. This feels like the nudge I needed to give jj a proper go. Thank you.