Remove a worktree. Only clean worktrees (no untracked files and no
modification in tracked files) can be removed. Unclean worktrees or ones
with submodules can be removed with `--force`. The main worktree cannot be
removed.

repair [<path>...]::

Repair worktree administrative files, if possible, if they have become
corrupted or outdated due to external factors.
+
For instance, if the main worktree (or bare repository) is moved, linked
worktrees will be unable to locate it. Running `repair` in the main
worktree will reestablish the connection from linked worktrees back to the
main worktree.
+
Similarly, if the working tree for a linked worktree is moved without
using `git worktree move`, the main worktree (or bare repository) will be
unable to locate it. Running `repair` within the recently-moved worktree
will reestablish the connection. If multiple linked worktrees are moved,
running `repair` from any worktree with each tree's new `<path>` as an
argument, will reestablish the connection to all the specified paths.
+
If both the main worktree and linked worktrees have been moved or copied manually,
then running `repair` in the main worktree and specifying the new `<path>`
of each linked worktree will reestablish all connections in both
directions.

unlock::

Unlock a worktree, allowing it to be pruned, moved or deleted.

OPTIONS
-------

-f::
--force::
	By default, `add` refuses to create a new worktree when
	`<commit-ish>` is a branch name and is already checked out by
	another worktree, or if `<path>` is already assigned to some
	worktree but is missing (for instance, if `<path>` was deleted
	manually). This option overrides these safeguards. To add a missing but
	locked worktree path, specify `--force` twice.
+
`move` refuses to move a locked worktree unless `--force` is specified
twice. If the destination is already assigned to some other worktree but is
missing (for instance, if `<new-path>` was deleted manually), then `--force`
allows the move to proceed; use `--force` twice if the destination is locked.
+
`remove` refuses to remove an unclean worktree unless `--force` is used.
To remove a locked worktree, specify `--force` twice.

-b <new-branch>::
-B <new-branch>::
	With `add`, create a new branch named `<new-branch>` starting at
	`<commit-ish>`, and check out `<new-branch>` into the new worktree.
	If `<commit-ish>` is omitted, it defaults to `HEAD`.
	By default, `-b` refuses to create a new branch if it already
	exists. `-B` overrides this safeguard, resetting `<new-branch>` to
	`<commit-ish>`.

-d::
--detach::
	With `add`, detach `HEAD` in the new worktree. See "DETACHED HEAD"
	in linkgit:git-checkout[1].

--[no-]checkout::
	By default, `add` checks out `<commit-ish>`, however, `--no-checkout` can
	be used to suppress checkout in order to make customizations,
	such as configuring sparse-checkout. See "Sparse checkout"
	in linkgit:git-read-tree[1].

--[no-]guess-remote::
	With `worktree add <path>`, without `<commit-ish>`, instead
	of creating a new branch from `HEAD`, if there exists a tracking
	branch in exactly one remote matching the basename of `<path>`,
	base the new branch on the remote-tracking branch, and mark
	the remote-tracking branch as "upstream" from the new branch.
+
This can also be set up as the default behaviour by using the
`worktree.guessRemote` config option.

--[no-]relative-paths::
	Link worktrees using relative paths or absolute paths (default).
	Overrides the `worktree.useRelativePaths` config option, see
	linkgit:git-config[1].
+
With `repair`, the linking files will be updated if there's an absolute/relative
mismatch, even if the links are correct.

--[no-]track::
	When creating a new branch, if `<commit-ish>` is a branch,
	mark it as "upstream" from the new branch.  This is the
	default if `<commit-ish>` is a remote-tracking branch.  See
	`--track` in linkgit:git-branch[1] for details.

--lock::
	Keep the worktree locked after creation. This is the
	equivalent of `git worktree lock` after