You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Replace the current 4-layer private content protection system (gitignore + .git/info/exclude + pre-commit hooks + content stripping) with a simpler architecture: private/ becomes a gitignored standalone nested git repo.
Problem
The current approach for protecting private content is complex and incomplete:
Loss risk: private/ is gitignored -- content is never truly version-controlled unless you switch to the private branch and commit
Cognitive overhead: 4-layer protection system is hard to reason about
No history: Design docs, postmortems, and analysis evolve but that evolution isn't tracked
Proposed Solution
Make private/ its own git repo, nested inside the project. The parent repo's .gitignore already excludes /private/, so the parent has zero awareness of the inner repo.
Why not submodules?
Approach
Verdict
Formal submodule
Rejected -- .gitmodules leaks info, branch-switching is hazardous, UX is poor
Gitignored nested repo
Winner -- zero visibility to parent, full history, simplest mental model
Subtree
Rejected -- embeds private content into parent history
Rollout
Phase 1: dz private-init command in dazzlecmd -- one command initializes private/ as its own repo
Phase 2: Integrate into repokit create / repokit adopt
Summary
Replace the current 4-layer private content protection system (gitignore +
.git/info/exclude+ pre-commit hooks + content stripping) with a simpler architecture:private/becomes a gitignored standalone nested git repo.Problem
The current approach for protecting private content is complex and incomplete:
private/is gitignored -- content is never truly version-controlled unless you switch to theprivatebranch and commitgithub/anddev/worktrees can't accessprivate/(Auto-create symlinks/junctions to private/ in public worktrees #6, Auto-create private/ junctions in worktrees + browser extension template #10)Proposed Solution
Make
private/its own git repo, nested inside the project. The parent repo's.gitignorealready excludes/private/, so the parent has zero awareness of the inner repo.Why not submodules?
.gitmodulesleaks info, branch-switching is hazardous, UX is poorRollout
dz private-initcommand in dazzlecmd -- one command initializesprivate/as its own reporepokit create/repokit adoptgit-repokit-private-template, implement worktree junctions (Auto-create symlinks/junctions to private/ in public worktrees #6)Impact on existing guardrails
.gitignore.git/info/excludepre-commithookprivate/Migration for existing projects
No parent repo changes needed --
private/is already gitignored.Related
Analysis
See
2026-04-02__21-57-43__private-folder-versioned-as-submodule-design.mdfor detailed analysis.