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