ghq rm previously used os.RemoveAll with no worktree awareness, which
caused two problems: removing a linked worktree left a dangling entry
in the parent repo's .git/worktrees/, and removing a repo that had
linked worktrees orphaned all of them.
Now ghq rm detects both scenarios:
- If the target is a linked worktree, use git worktree remove to
properly unregister it from the parent repo.
- If the target repo has linked worktrees, prune each one before
removing the main repo.
Extract shared worktree helpers into worktree.go so both cmd_rm.go
and cmd_migrate.go can reuse them.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The repairWorktreeBackPointers function was failing to detect internal
worktrees on Windows because Git writes paths with forward slashes in
gitdir files, but the code was comparing them with backslash paths.
- Normalize oldDir to forward slashes for comparison
- Normalize wtPath read from gitdir file for comparison
- Write updated gitdir with forward slashes (Git's format)
- Fix wtDir trimming to use forward slash separator
This fixes both the back-pointer repair and the paths passed to
'git worktree repair' on Windows.
Co-authored-by: Songmu <177122+Songmu@users.noreply.github.com>
The migrate command had no awareness of Git worktrees or submodules,
which are linked checkouts with a .git file referencing a parent repo.
This adds three capabilities:
- Detects linked checkouts (.git file with gitdir: reference) and
refuses migration with a descriptive error, since moving them
independently always breaks the link.
- After migrating a repo with linked worktrees, runs
'git worktree repair' to update forward references (worktree .git
files) back to the new main repo location.
- Handles internal worktrees (inside the repo directory) by rewriting
stale back-pointers (.git/worktrees/*/gitdir) before repair, since
both directions become stale when the worktree moves with the repo.
