Skip to content

fix: prevent recursive .bak trees during gstack upgrade - #922

Closed
aylint wants to merge 1 commit into
garrytan:mainfrom
aylint:fix/upgrade-recursive-backups
Closed

aylint wants to merge 1 commit into
garrytan:mainfrom
aylint:fix/upgrade-recursive-backups

Conversation

@aylint

@aylint aylint commented Apr 8, 2026

Copy link
Copy Markdown

Summary

Fixes a /gstack-upgrade bug that could create recursive backup trees during repeated upgrades.

The issue had two paths:

  • The upgrade flow copied the primary install into a vendored copy without excluding .bak*
  • Git-based installs could keep old top-level .bak* directories around because git reset --hard does not remove untracked backup dirs

What Changed

  • Purge top-level .bak* after git reset --hard
  • Replace vendored sync cp -Rf with rsync, excluding .git and .bak*
  • Scrub any leftover top-level .bak* after vendored sync
  • Add a regression test covering the generated upgrade instructions

Validation

Ran:

  • bun run gen:skill-docs
  • bun run skill:check
  • bun test
  • bun test test/gen-skill-docs.test.ts

Notes:

  • The upgrade fix itself is clean and scoped to 3 files
  • Some repo-wide failures are already present on origin/main and are not caused by this PR:
    • bun run skill:check fails because multi-host generated skill trees are stale upstream
    • test/host-config.test.ts has stale/missing golden-host outputs upstream
    • test/team-mode.test.ts times out upstream
    • browse/test/commands.test.ts and browse/test/snapshot.test.ts fail with EADDRINUSE upstream in this environment

User Impact

/gstack-upgrade no longer copies backup trees into vendored installs. Git-based upgrades now clear stale top-level .bak* directories, and vendored sync excludes .bak* to prevent backups from recursing during repeated upgrades.

time-attack pushed a commit to time-attack/gstack that referenced this pull request Jul 14, 2026
An interrupted upgrade leaves the previous .bak directory in place; the
next run's 'mv X X.bak' then moves the install INSIDE the stale backup
(X.bak/gstack), nesting one level deeper on every retry — the recursive
.bak trees reported in garrytan#922. rm -rf the stale backup before each mv at
both backup sites (vendored Step 4 and local-copy Step 4.5).

Root-cause replacement for PR garrytan#922 (reported the problem; its cleanup
globs matched '.bak*' basenames the flow never creates).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@capy-ai

capy-ai Bot commented Oct 3, 2026

Copy link
Copy Markdown
Contributor

Thanks for this, @aylint. The fix is now on main: /gstack-upgrade refuses to run over a stale .bak and swaps directories with mv instead of nesting copies (gstack-upgrade/SKILL.md.tmpl) (fixed in v1.91.16.0, #3014). Closing as superseded; if you still see the problem on the latest gstack, please open an issue with ./setup --status output.

@capy-ai capy-ai Bot closed this Oct 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant