Best practice for Git worktrees inside a multi-repo folder

[rancid summit]

Hey everyone 👋
I’m looking for advice on a Git + Cursor workflow.

I have a top-level repo that contains multiple sub-repos.
In Cursor, I usually open the entire top-level folder so it has full context across all repos.

What I’m trying to do is use Git worktrees per sub-repo, only when needed, without breaking this setup.

Conceptually, my folder structure looks like this:

top-level-repo/
├─ sub-repo-1/
├─ sub-repo-1-worktree-a/
├─ sub-repo-1-worktree-b/
│
├─ sub-repo-2/
├─ sub-repo-2-worktree-a/
├─ sub-repo-2-worktree-b/

What I’m trying to solve:

• How to create and manage Git worktrees per sub-repo on demand
• Whether there’s a recommended directory structure for this
• How to prevent Cursor from indexing all worktrees
  • Indexing everything leads to duplicated symbols, confusion, and AI hallucinations
  • Ideally, only the active worktree(s) should be indexed

Has anyone set this up cleanly—especially when using Cursor with a mono-folder workflow?
Any practical workflows, tooling tips, or gotchas would be appreciated 🙏

I can of course add/remove worktrees on demand from .cursorignore - but that's not exactly what I want..

[fallow schooner]

Why are your worktrees living inside of the top repo, it should be a completely different folder

By default cursor places worktrees in ~/.cursor/worktrees

[rancid summit]

@fallow schooner Well it's not really worktrees - but just repos inside a big repo (with submodules) - shouldn't I do that? 🤔

[fallow schooner]

That one is fine, but how come in your tree you say the worktree is inside of top level?

[rancid summit]

Because I have repo inside repo, and then for the inner repo - I wanna have a second worktree. that's all I wanna do - doesn't make sense?

[fallow schooner]

Yeah, I understand this, no worries

Worktrees just have to be completely separate from the repo it is from, since it's a submodule, your main repo still sees it

But like I said though, cursor creates worktrees by default in ~/.cursor/worktrees, so were these worktrees something you made manually?

The fix is to make the worktree completely separate from your root

[rancid summit]

Oh I see - and if it'll create it in ~/.cursor/worktrees - so it'd work well?

[fallow schooner]

Which folder you have open in cursor? sub-repo-1? If so, then yeah

[rancid summit]

nope, opened the top-level-repo

[fallow schooner]

⁨```
top-level-repo/
├─ sub-repo-1/
├─ sub-repo-2/

~/.cursor/worktrees/top-level-repo-some-j4fj/
├─ sub-repo-1/
├─ sub-repo-2/

[rancid summit]

That's what I'm asking about - I know I can make it work when I open the subrepo folder in Cursor. I'm just wondering how to do that when I open the top-level-repo folder.

[fallow schooner]

it will become like this

[rancid summit]

Yeahh, not sure if that's what I want

If that'd happen, I suspect it won't be able to manage the sub-repos branches etc

interesting

[fallow schooner]

it has to be this way, you can't make worktrees live in the root folder, your git will explode

[fallow schooner]

it does, git supports this, git was designed with that in mind, git worktree state is shared in the "true" repo

if you use a git gui you with worktree support, you will see it as just any other branch

but worktree branch has a special thing where it simply lives in another folder

this makes it so the agent is able to work on two different branches at once and not fight each other

without worktrees, files will get overwritten when you checkout

i think you misunderstood how worktrees work @rancid summit

i was confused how they worked at first too

[rancid summit]

interesting, I'll try now and update

thx thx thx

As you said, I've probably misunderstood worktrees

[fallow schooner]

the worktree copies are still linked to the main git repo, it's a copy of the main repo essentially, they're not something that cursor made but it's ⁨git⁩ what handles it itself

GitKraken supports them and they show up as like this

It looks like a normal branch, but it has a tree icon

When I double click to checkout the worktree, it's almost the same as a normal checkout

[rancid summit]

Well - I have just tested it.
Again - what I'm trying to achieve is a new worktree for the subrepo when the top-level-repo folder is open.
It created a new worktree for the top-level-repo, but then when I asked it to switch to another branch for the subrepo - it switched it for both the worktree and the normal working dir...

the subrepos aren't really in the top-level-repo, they're just subrepos.
Maybe I need to configure something in worktrees.json/setup-worktree