Skip to content

Add support for moving a worktree to a new location #66

Description

@shmuelie

Summary

Add support for moving an existing worktree to a new filesystem location. The worktree helpers can create, list, navigate to, and remove worktrees, but there is no command to relocate a worktree once it exists. Today the only path is to drop to raw git worktree move, which also leaves any derived path bookkeeping untouched.

Motivation

  • Reorganizing worktrees on disk (e.g. conforming to a standard <container>/<branch> layout, moving to a different drive, or renaming a directory) currently requires manual git worktree move plus manual cleanup.
  • A first-class command keeps the operation consistent with the rest of the worktree helper surface (discoverable, tab-completable branch names, -WhatIf/-Confirm, typed results).

Proposed capability

A cmdlet that moves a worktree identified by its branch (consistent with how the other worktree commands are addressed) to a caller-supplied destination path, wrapping git worktree move.

Suggested behavior:

  • Accept the worktree to move by branch name (with tab-completion / validation from the current repo's worktrees) and a destination path.
  • Support pipeline input by property name so a worktree object can be piped in, matching the other worktree cmdlets.
  • Refuse to move the main/root worktree (git itself disallows this) with a clear error.
  • Surface git's own guard rails (locked worktrees, destination already exists) as clear errors; optionally expose a -Force switch that maps to git worktree move --force for the cases git allows it.
  • Implement [CmdletBinding(SupportsShouldProcess)] and honor -WhatIf/-Confirm, since this is a state-changing operation.
  • Optionally offer a switch to Set-Location into the new path after a successful move.

Acceptance criteria

  • A worktree can be moved to a new location by specifying its branch and a destination path, without the caller invoking raw git.
  • Attempting to move the main/root worktree fails with a clear, actionable error.
  • The command honors -WhatIf and -Confirm and performs no move under -WhatIf.
  • Failures reported by git (destination exists, locked worktree, etc.) are surfaced clearly rather than silently swallowed.
  • Branch-name argument offers completion/validation from the current repository's worktrees, consistent with the existing worktree commands.
  • Ships with Pester tests and a README/CHANGELOG ([Unreleased]) entry.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions