How can I rename a git worktree

Question

Given I have run

$ git worktree add ~/worktrees/a
$ cd ~/worktrees/a
$ git status
On branch a

I would like to instead change the name of the worktree and branch from a to b.

Goltz

Answer 1

One option for achieving this (that I ended up doing) is:

$ git worktree move ~/worktrees/a ~/worktrees/b
$ cd ~/worktrees/b
$ git branch -m b

Goltz

That's pretty much the way to go. Note that worktrees don't have things that everyone would call a "name", but rather have a path (which others call a path-name or pathname, so it's not unreasonable to call it a "name" after all, but I at least was confused by what you meant). They do, however, have a current branch, or are on a detached HEAD, and when they are on a branch it's pretty common to have the last component of the path name match the branch name. So moving the path and renaming the branch is the right way to get where you want to be. – Dowry

Thanks for your comment @torek. TIL and that seems like pretty useful info in understanding worktrees now that I started using them. But why the distinction? I'm guessing you can have some "non-standard" place you alternatively store each worktree rather than under the same root where the "bare repo" (what my tutorial called it) is stored? Trying to think why that would be desirable. – Hoshi

@GregCobb: a "bare" repository is something different: it's a repository with no working tree. The point of having a bare repository is so that it has no working tree; adding a working tree to a bare repository kind of defeats that purpose. It would make sense mathematically (and logically!) if all Git repositories started out as bare, but that's not how Git evolved: a "normal" repository always had exactly one working tree. The git worktree command came about because people find it useful to have more than one working tree. – Dowry

@GregCobb: this does leave us with a sort-of-unnecessary distinction between "default" and "added" working trees. Git has to make that distinction now because a normal clone does have a default working tree, though, so short of breaking backwards compatibility with older Git versions, we're stuck with the distinction. – Dowry

Note: The path to the information about the worktree might still be located at .git/worktrees/a (!) – Unwieldy

After cd ~/worktrees/b you should run git worktree repair to restablish the connection to the main tree. If you also moved the main tree then use git worktree repair [path-to-worktree] inside the main tree. See documentation. – Wetnurse

Answer 2

Not a git expert, but I feels like git worktree move <worktree> <new-path> would do the trick.

See the official documentation.

Friedman