Feature Request: Support workspace-scoped (directory-scoped) configuration

[witt-bit]

Summary

Currently Worktrunk supports three configuration scopes:

• System
• User
• Project

However, there is no way to apply the same configuration to a group of repositories located under the same workspace directory.

This becomes difficult to manage for organizations with many repositories.

Motivation

In many companies, repositories are organized under a common workspace.

For example:

~/codes/
├── workspace/
│   ├── service-a
│   ├── service-b
│   ├── service-c
│   ├── ...
│   └── worktrees/
├── personal/
└── opensource/

All repositories under ~/codes/workspace share exactly the same Worktrunk configuration:

• identical worktree layout
• identical aliases
• identical hooks
• identical commit generation settings

In our case, this workspace contains 100+ repositories.

The current options are not ideal:

• User Config applies globally, including personal and open-source repositories, which often require different settings.
• Project Config requires copying the same configuration into every repository, making it difficult to maintain and violating the DRY principle.

Whenever the shared configuration changes, it must be updated across every repository.

Proposed Solution

Introduce a new configuration scope between User and Project.

For example:

System
    ↓
User
    ↓
Workspace (Directory)
    ↓
Project

One possible implementation could be a workspace configuration file:

~/codes/workspace/.worktrunk/config.toml

which automatically applies to every Git repository under that directory.

Another option would be a Git-style conditional include mechanism, similar to gitconfig:

[[include_if]]
gitdir = "~/codes/workspace/**"
path = "~/.config/worktrunk/company.toml"

[[include_if]]
gitdir = "~/codes/personal/**"
path = "~/.config/worktrunk/personal.toml"

This approach would be more flexible and familiar to Git users.

Benefits

• Configure hundreds of repositories only once.
• Keep company and personal configurations completely separate.
• Avoid duplicated project configuration.
• Reduce maintenance overhead.
• Align with Git's existing configuration model (includeIf).

I believe this would significantly improve Worktrunk for developers who manage multiple repositories across different workspaces.

[worktrunk-bot]

Thanks for the detailed write-up — the 100+-repo DRY problem is real and there's no directory/workspace scope today: config resolves through fixed platform paths (system, user) and a single per-repo .config/wt.toml; nothing walks parent directories, and there's no includeIf-style conditional include.

The closest existing mechanism is the [projects] table in user config — it lets user config carry per-repo overrides (worktree layout, hooks, aliases, etc.) without touching each repo. But it's keyed by exact project identifier (host/owner/repo, exact-match — no globs), so for your workspace it'd mean one entry per repo — better than duplicating .config/wt.toml files, but not the "configure once for the whole directory" you're after.

Worth flagging that this request has prior history: #1413 proposed the parent-directory-walking variant (your option A — a .worktrunk/config.toml that cascades down to child repos) and was closed after a long discussion. The maintainer's stance there was that the user is sovereign over layout config, and inheritance that keys on directory structure assumes a repo arrangement worktrunk can't count on ("how do we know the paths will be organized this way?").

Your option B (git-style includeIf) is the part that reads as materially new against that thread, because it sidesteps both objections: it lives in user config (the user stays sovereign — nothing reaches in from a parent directory), and the user explicitly declares which gitdir glob maps to which config file rather than worktrunk inferring a layout. That's a meaningfully different design from the parent-walk that was declined, and it's the framing I'd lead with if you want to make the case.

I'll leave it for a maintainer to evaluate and prioritize — but given #1413, the includeIf angle (user-declared, not layout-inferred) is the one most likely to move the needle.

Where this would slot in, for whoever picks it up

• Scopes today merge in two pipelines (src/config/mod.rs): the UserConfig layering (system → user → env → CLI) via deep_merge_table in src/config/user/mod.rs, and the typed per-project/project-config merge on top of the resolved UserConfig.
• An includeIf-shaped layer (same UserConfig schema, git semantics) would slot in as a new file layer between the user layer and the env overlay — after src/config/user/mod.rs#L525 — reusing deep_merge_table, plus a ConfigFileKind::Workspace variant. The only genuinely new code is the glob-match/resolution of the included path; no existing loader walks or matches directories.
• Per-project override map (the closest analogue) is keyed by identifier computed in src/git/repository/remotes.rs and looked up with an exact HashMap::get — no glob today.

Prior discussion: #1413 (parent-directory inheritance, closed). Related: #980 (multi-repo workflows).