fix(scripts): don't run git worktree prune under --dry-run - #272
Merged
Conversation
cleanup-branches.sh's dry-run mode is documented as 'list what would be removed, change nothing', but the trailing git worktree prune call ran unconditionally regardless of the flag. On at least one Windows/Git-Bash setup, that prune misjudged every registered worktree as stale even though their directories were all present and unmodified, wiping .git/worktrees/<name>/ bookkeeping for ~29 worktrees from a single --dry-run invocation. No branches, commits, or worktree files were lost (prune only removes admin state), but every affected worktree needs manual re-registration. git worktree remove already drops the admin entry for anything it actually removes, so prune only matters on a real (non-dry-run) pass.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe branch cleanup script now skips the destructive ChangesBranch cleanup
Estimated code review effort: 1 (Trivial) | ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
getappz
added a commit
that referenced
this pull request
Jul 28, 2026
…sk 9 provisioning (#354) * feat(skill): finish EPIC #272 Task 6 write-path + Task 9 provisioning Task 6 (proactive advisory): proactive_suggestions()/settings read-path already existed (PR #302) but had no way to actually set a snooze or dismiss - save_settings() was dead code. Add `skill snooze <name> [--days N]` and `skill dismiss <name>` wired to it. Task 9 (repo stack -> auto provisioning): new `skill provision <path>` subcommand. Detects stack via manifest files (Cargo.toml/package.json/ tsconfig.json/pyproject.toml/requirements.txt/go.mod), ranks indexed skills against it via BM25 search, prints a dry-run report (skills, confidence, token cost) with zero DB writes, and on --yes re-tags the matched entries under source "provisioned:<repo>" via the existing scan+rebuild entry-creation path. * fix(skill): address CodeRabbit findings on provision/snooze - rank_candidates picked the highest bm25 score as "best" and sorted descending; bm25 is negative-is-better (search.rs sorts ASC on the same raw value), so this had it backwards. Flip to min-selection + ascending sort, add confidence_pct() for a bounded 0-100 display value instead of the broken score.min(1.0)*100.0. - run_provision --yes rebuilt the DB from a fresh flat-dir scan only, and rebuild() is full-replace -- silently dropping any other provisioned:*/imported:*/hub:* DB-only rows on every run. Merge existing DB rows (via list_all_name_source_pairs + load, same reconstruction run_export already uses) before rebuilding, mirroring HubAction::Pull's merge-before-rebuild shape. - Use crate::components::detected_skill_agents() instead of a hardcoded ["claude-code"] source list. - snooze() clamped days to >=0 but not the upper bound; saturating_add from a large --days no longer risks i64 overflow. - New adversarial rank_candidates test (two same-tag matches of different strength) -- the previous test had only one candidate per tag, so it couldn't have caught the sign inversion.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
cleanup-branches.sh --dry-runis documented as "list what would be removed, change nothing", but the trailinggit worktree pruneran unconditionally, outside theDRY_RUNgate everything else in the script respects.Hit this live: running
cleanup:branches --dry-run(via themiseMCP task runner) wiped.git/worktrees/<name>/registration for ~29 worktrees in one shot on a Windows/Git-Bash checkout —git worktree pruneapparently misjudged every present, unmodified worktree directory as stale. No data loss (prune only removes admin bookkeeping, never branches/commits/files), but every affected worktree now needs manual re-registration.Fix
Gate the
prunecall behind the same((DRY_RUN))check as the rest of the script.Test plan
bash -n scripts/cleanup-branches.sh— syntax OKgit worktree remove(real-run path) already drops its own admin entry, soprunewas only ever needed to sweep entries for worktrees removed some other way — never a--dry-runconcern.Summary by CodeRabbit