docs(git-workflow): guard against basing decisions on a stale worktree#100
Conversation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
There was a problem hiding this comment.
Code Review
This pull request adds a new section to the advanced git documentation regarding the risks of using stale worktrees. The reviewer suggested a correction to the git fetch command to ensure it is properly scoped to the repository and recommended a safer workflow for inspecting commits before pushing, providing a specific code suggestion and reference.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Add an "A stale worktree is a stale source" subsection: before deciding from what a repo contains (dependency constraints, whether a fix is on main, a signature to code against), read origin/main or a fresh worktree — not the stale checkout. Covers reporting a stale value as fact, subagents reading a stale tree, and verifying a dependency signature at the resolved version. Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
Signed-off-by: Sebastian Mendel <info@sebastianmendel.de>
870145d to
0d01232
Compare
|



Adds a short "A stale worktree is a stale source" subsection to
references/advanced-git.md(Worktrees).Why: a worktree checked out days ago is whatever it was then — its
composer.json, its "what's on main", its API signatures. Basing a decision on the stale checkout (and reporting the old value as fact) is a recurring failure. Real case: reporting a dependency constraint as^0.13from an un-fetched worktree when currentmainalready said^0.17 || ^0.18 || ^0.19.What it adds:
origin/main(or read a fresh worktree) before deciding from repo contents.vendor/.Build), not the library'smain.Docs-only.