Any way to have nested workspaces?

[proshin-roman]

Dear community! Dear author!

I installed the app, the plan was to use the TUI for managing my workspace: a set of Git repos with nested and flat worktrees. My worktrees might be either inside the Git repos (the "Claude way") or next to the main repo (the "Jetbrains way"). In general, GWM TUI supports both, so there is nothing I'd have to change in my setup.
However, I also have a nested workspace: a directory that is not directly a Git repo, but contains a set of Git repos. Somehow, this directory is not even considered by the GWM TUI. I've searched in the docs if there is an configuration option - smth like "depth" - but couldn't find anything. It seems the whole idea is not supported.

Am I missing something or the app doesn't support such a nested structure? Shall I file a feature request?

Thank you!

[niravpatidar37]

You are not missing a setting. As of v1.10.0 (and current main), workspace mode only looks one level deep, and there is no depth option or workspace-level config. A directory that is not itself a repo but contains repos is skipped when it sits under the workspace root.

Where this lives in the code

• workspace::discover does a single read_dir(root) and calls Repository::open on each direct child; non-repo directories are skipped. The doc comment says it outright: "nested repos two levels down are not discovered (workspace mode is intentionally shallow)". src/workspace.rs#L51-L77
• --workspace takes one DIR, described as "every git repo one level below ". src/cli.rs#L56-L66
• The TUI uses the same function, so the TUI, list, create, exec and clean all see the same set of repos. src/tui/app.rs#L986-L988

Workaround that works today: symlink the nested repos up one level

discover follows symlinked directories and resolves each one to the repo's real path. So you can point it at your nested repos without moving anything:

# inside the existing workspace root
cd ~/Projects
ln -s group/svc-a svc-a
ln -s group/svc-b svc-b
gwm --workspace ~/Projects

Or keep a separate "view" directory made only of symlinks:

mkdir ~/gwm-view
ln -s ~/Projects/api ~/Projects/web ~/Projects/group/svc-a ~/Projects/group/svc-b ~/gwm-view/
gwm --workspace ~/gwm-view

I tested this with the v1.10.0 Linux release binary. Layout: /ws/{api,web} are repos, /ws/group is a plain directory holding repos svc-a and svc-b, plus worktrees both inside a repo (api/.worktrees/feat-in) and next to it (api-feat-next, group/svc-a-feat-a).

Command	Repos shown
gwm list --workspace /ws	api, web (group/* missing)
gwm list --workspace /ws/group	svc-a, svc-b
gwm list --workspace /ws --workspace /ws/group	error: the argument '--workspace <DIR>' cannot be used multiple times
/ws + symlinks svc-a, svc-b	api, svc-a, svc-b, web, with all 8 worktrees and real paths (/ws/group/svc-a/)
symlink-only dir /all	same as above; gwm --workspace /all create feat 1 demo --repo svc-b created the worktree in the nested repo

Caveats:

• If two nested repos share a basename, gwm shows them as name and name-2 (src/workspace.rs#L120-L138), so --repo names may not be what you expect.
• New nested repos need a new symlink. Nothing picks them up automatically.

Feature request

I think a feature request is worth filing. The change would go in the read_dir loop in src/workspace.rs#L59-L113: when a directory is not a repo, look inside it, up to a configurable depth. It should not descend into repos, which also keeps in-repo worktrees from showing up twice. Since the comment calls the shallow behaviour intentional, it's worth asking for it as opt-in (for example a depth setting), not as a change to the default.

Tested with gwm 1.10.0 (x86_64-unknown-linux-gnu release, checksum verified), git 2.43, Ubuntu 24.04 container.
Not tested: the interactive TUI itself (I used gwm list/create, which use the same discovery code), and symlinks on macOS or Windows (on Windows, creating symlinks usually requires Developer Mode or admin rights).