Context
PR #113 closes #110 by requiring that a git worktree, where one is used at all, be created inside the repository checkout (e.g. .worktrees/<branch>, added to .git/info/exclude) rather than in /tmp, and by telling headless dispatches not to create one at all.
#110 raised a second question that PR #113 does not answer:
Worth checking whether .worktrees/ inside the checkout interacts badly with the git clean -fdx that gardener's refresh runs.
Why it was left unanswered rather than guessed at
A code search against Stephenson-Software/gardener was denied by the dispatched session's tool allow-list, so gardener's refresh behavior could not be read from source. Asserting how another project cleans its managed checkouts without having read that code would have put an unverified claim into the template, which is worse than an acknowledged gap.
What is and is not at risk
The headless half is already sidestepped: a gardener tend run is now told not to create a worktree at all, since it owns a clone dedicated to it and has no concurrent session to collide with. Nothing gardener does to .worktrees/ can matter if the directory is never created there.
The interactive half remains open. If a maintainer creates .worktrees/<branch> interactively in a checkout that gardener later refreshes, and that refresh runs git clean -fdx, then the guidance's own recommendation — excluding the directory via .git/info/exclude — is what makes it removable, since -x deletes ignored files. The worktree's contents would be destroyed while stale administrative data remained under .git/worktrees/, requiring git worktree prune.
What would resolve this
Reading gardener's refresh path and then either:
- confirming that
.worktrees/ is safe (it is not cleaned, or gardener does not refresh checkouts a human works in), and recording that in the Edge cases entry so the question is not re-asked; or
- confirming that it is unsafe, and narrowing the guidance further — for example, stating that the worktree workflow is for interactive sessions on checkouts no automation manages, and that every other context should use the checkout directly.
Either outcome is a one-line change to the same Edge cases entry PR #113 touches.
This issue body was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).
drafted by Claude on behalf of Daniel Stephenson
Context
PR #113 closes #110 by requiring that a
git worktree, where one is used at all, be created inside the repository checkout (e.g..worktrees/<branch>, added to.git/info/exclude) rather than in/tmp, and by telling headless dispatches not to create one at all.#110 raised a second question that PR #113 does not answer:
Why it was left unanswered rather than guessed at
A code search against
Stephenson-Software/gardenerwas denied by the dispatched session's tool allow-list, so gardener's refresh behavior could not be read from source. Asserting how another project cleans its managed checkouts without having read that code would have put an unverified claim into the template, which is worse than an acknowledged gap.What is and is not at risk
The headless half is already sidestepped: a
gardener tendrun is now told not to create a worktree at all, since it owns a clone dedicated to it and has no concurrent session to collide with. Nothing gardener does to.worktrees/can matter if the directory is never created there.The interactive half remains open. If a maintainer creates
.worktrees/<branch>interactively in a checkout that gardener later refreshes, and that refresh runsgit clean -fdx, then the guidance's own recommendation — excluding the directory via.git/info/exclude— is what makes it removable, since-xdeletes ignored files. The worktree's contents would be destroyed while stale administrative data remained under.git/worktrees/, requiringgit worktree prune.What would resolve this
Reading gardener's refresh path and then either:
.worktrees/is safe (it is not cleaned, or gardener does not refresh checkouts a human works in), and recording that in the Edge cases entry so the question is not re-asked; orEither outcome is a one-line change to the same Edge cases entry PR #113 touches.
This issue body was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).
drafted by Claude on behalf of Daniel Stephenson