Skip to content

Commit 5f3c865

Browse files
joaoh82claude
andauthored
chore(release): fix bump-version.sh commit-message hint + untrack accidental worktree gitlinks (#135)
* chore: untrack accidental .claude/worktrees/ gitlinks + add to .gitignore The v0.10.0 release commit (937f8b4) captured 8 worktree directories as gitlinks (mode 160000) because `scripts/bump-version.sh` ran `git add -A` while the per-phase worktrees were live in .claude/worktrees/. They aren't real submodules — no `.gitmodules`, no remote — just orphan gitlink references to commits on the now-deleted `worktree-phase-*` branches. Removing the gitlink entries from the index now that the worktrees have been cleaned up. Adding .claude/worktrees/ to .gitignore so the next round of phase worktrees doesn't repeat the issue. Not rewriting v0.10.0's history — the release tag is already published, and the orphan gitlinks there don't break anything for consumers (no .gitmodules → git won't try to fetch them on clone). Forward state is clean from this commit on. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(release): bump-version.sh prints the workflow-expected commit message Followup from the v0.10.0 release misfire. `scripts/bump-version.sh` correctly bumps all 11 manifests but doesn't tell the user what to do next, so a freshly-run script + a manual `git commit -m "chore(release): bump to <V>"` is a natural shape that silently skips the publish pipeline (the release workflow's detect regex is ^release: v[0-9]+\.[0-9]+\.[0-9]+$ and rejects everything else). The release-pr.yml workflow path (the "happy" path) already emits the right commit message; this fix is for the manual-fallback path that the v0.10.0 release used. - Print the exact `git commit -am 'release: v<V>'` line. - Print the recovery command (`gh workflow run release.yml -f version=<V>`) for cases when the wrong commit message has already been pushed. Also includes the .claude/worktrees/ gitlink cleanup that was an unrelated side-effect of the v0.10.0 bump commit picking up live worktree directories as gitlinks (mode 160000) via `git add -A`. Adds .claude/worktrees/ to .gitignore so the next round of phase worktrees doesn't repeat the issue, and untracks the 8 orphan gitlink entries. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 parent 937f8b4 commit 5f3c865

11 files changed

Lines changed: 27 additions & 12 deletions
Lines changed: 0 additions & 1 deletion
This file was deleted.
Lines changed: 0 additions & 1 deletion
This file was deleted.
Lines changed: 0 additions & 1 deletion
This file was deleted.
Lines changed: 0 additions & 1 deletion
This file was deleted.
Lines changed: 0 additions & 1 deletion
This file was deleted.
Lines changed: 0 additions & 1 deletion
This file was deleted.

.claude/worktrees/phase-11-6-gc

Lines changed: 0 additions & 1 deletion
This file was deleted.
Lines changed: 0 additions & 1 deletion
This file was deleted.
Lines changed: 0 additions & 1 deletion
This file was deleted.

.gitignore

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -44,3 +44,12 @@ examples/wasm/pkg
4444

4545
# macOS
4646
.DS_Store
47+
48+
# Local agent / Claude Code worktrees. These shouldn't ever get
49+
# committed — but `git add -A` from main while a worktree is live
50+
# under .claude/worktrees/<name>/ will capture it as a gitlink
51+
# (mode 160000) because the worktree dir looks like a submodule to
52+
# the parent index. Ignoring the whole tree prevents that whole
53+
# class of accident. (The release commit 937f8b4 hit exactly this
54+
# bug; the next commit untracks the leftover gitlinks.)
55+
.claude/worktrees/

0 commit comments

Comments
 (0)