Context
The repository currently tracks .ccb/ccb.config (explicitly whitelisted in .gitignore via !.ccb/ccb.config). For every fork maintainer who runs ccb from within the repo directory during development, this creates friction: the committed config's agent naming (agent1..agent5) diverges from whatever the developer uses in their daily CCB project (e.g. a1/a2/a3), leading to confusing unknown agent: ... errors when running commands from repo-relative paths.
The workaround I'm currently using: git update-index --skip-worktree .ccb/ccb.config plus a locally rewritten .ccb/ccb.config. This works for me but requires every CCB fork maintainer to discover the same workaround independently.
Question
Before proposing a change, I'd like to understand the original intent:
- Was
.ccb/ccb.config intentionally committed and whitelisted because some part of the test suite / dev tooling depends on its presence at repo root?
- Is the particular content (
cmd, agent1:codex; agent2:codex, agent3:claude; agent4:codex, agent5:gemini) significant, or is it just a maintainer's sample that happens to be in the repo?
Proposal if there is no strong reason to keep it
I'm happy to prepare a PR along the following lines, subject to your approval:
- Rename
.ccb/ccb.config → .ccb/ccb.config.example (so the sample stays in the repo as a reference)
- Remove
!.ccb/ccb.config from .gitignore; add .ccb/ccb.config (without the !) so local runtime config is ignored
- Adjust any test paths that reference the old path
- Add a one-liner note in
README / docs/ pointing developers to cp .ccb/ccb.config.example .ccb/ccb.config on first checkout
Benefits:
- Fork maintainers stop accidentally committing local-only agent naming to their fork branches
git status stays clean for people who customize their dev CCB agent list- The example config stays in-tree as documentation
Drawbacks:
- One-time bootstrap step for new contributors (a copy command, once)
- If CI / install flow currently assumes
.ccb/ccb.config exists at repo root, that flow would need to copy from .example first
Let me know if this is worth pursuing and whether there are concerns I should address in the PR.
Related
Context
The repository currently tracks
.ccb/ccb.config(explicitly whitelisted in.gitignorevia!.ccb/ccb.config). For every fork maintainer who runsccbfrom within the repo directory during development, this creates friction: the committed config's agent naming (agent1..agent5) diverges from whatever the developer uses in their daily CCB project (e.g.a1/a2/a3), leading to confusingunknown agent: ...errors when running commands from repo-relative paths.The workaround I'm currently using:
git update-index --skip-worktree .ccb/ccb.configplus a locally rewritten.ccb/ccb.config. This works for me but requires every CCB fork maintainer to discover the same workaround independently.Question
Before proposing a change, I'd like to understand the original intent:
.ccb/ccb.configintentionally committed and whitelisted because some part of the test suite / dev tooling depends on its presence at repo root?cmd, agent1:codex; agent2:codex, agent3:claude; agent4:codex, agent5:gemini) significant, or is it just a maintainer's sample that happens to be in the repo?Proposal if there is no strong reason to keep it
I'm happy to prepare a PR along the following lines, subject to your approval:
.ccb/ccb.config→.ccb/ccb.config.example(so the sample stays in the repo as a reference)!.ccb/ccb.configfrom.gitignore; add.ccb/ccb.config(without the!) so local runtime config is ignoredREADME/docs/pointing developers tocp .ccb/ccb.config.example .ccb/ccb.configon first checkoutBenefits:
git statusstays clean for people who customize their dev CCB agent listDrawbacks:
.ccb/ccb.configexists at repo root, that flow would need to copy from.examplefirstLet me know if this is worth pursuing and whether there are concerns I should address in the PR.
Related