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 `git worktree add`,
	but without a race condition.

-n::
--dry-run::
	With `prune`, do not remove anything; just report what it would
	remove.

--orphan::
	With `add`, make the new worktree and index empty, associating
	the worktree with a new unborn branch named `<new-branch>`.

--porcelain::
	With `list`, output in an easy-to-parse format for scripts.
	This format will remain stable across Git versions and regardless of user
	configuration.  It is recommended to combine this with `-z`.
	See below for details.

-z::
	Terminate each line with a NUL rather than a newline when
	`--porcelain` is specified with `list`. This makes it possible
	to parse the output when a worktree path contains a newline
	character.

-q::
--quiet::
	With `add`, suppress feedback messages.

-v::
--verbose::
	With `prune`, report all removals.
+
With `list`, output additional information about worktrees (see below).

--expire <time>::
	With `prune`, only expire unused worktrees older than `<time>`.
+
With `list`, annotate missing worktrees as prunable if they are older than
`<time>`.

--reason <string>::
	With `lock` or with `add --lock`, an explanation why the worktree
	is locked.

<worktree>::
	Worktrees can be identified by path, either relative or absolute.
+
If the last path components in the worktree's path is unique among
worktrees, it can be used to identify a worktree. For example if you only
have two worktrees, at `/abc/def/ghi` and `/abc/def/ggg`, then `ghi` or
`def/ghi` is enough to point to the former worktree.

REFS
----
When using multiple worktrees, some refs are shared between all worktrees,
but others are specific to an individual worktree. One example is `HEAD`,
which is different for each worktree. This section is about the sharing
rules and how to access refs of one worktree from another.

In general, all pseudo refs are per-worktree and all refs starting with
`refs/` are shared. Pseudo refs are ones like `HEAD` which are directly
under `$GIT_DIR` instead of inside `$GIT_DIR/refs`. There are exceptions,
however: refs inside `refs/bisect`, `refs/worktree` and `refs/rewritten` are
not shared.

Refs that are per-worktree can still be accessed from another worktree via
two special paths, `main-worktree` and `worktrees`. The former gives
access to per-worktree refs of the main worktree, while the latter to all
linked worktrees.

For example, `main-worktree/HEAD` or `main-worktree/refs/bisect/good`
resolve to the same value as the main worktree's `HEAD` and
`refs/bisect/good` respectively. Similarly, `worktrees/foo/HEAD` or
`worktrees/bar/refs/bisect/bad` are the same as
`$GIT_COMMON_DIR/worktrees/foo/HEAD` and
`$GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad`.

To access refs, it's best not to look inside `$GIT_DIR` directly. Instead
use commands such as linkgit:git-rev-parse[1] or linkgit:git-update-ref[1]
which will handle refs correctly.

CONFIGURATION FILE
------------------
By default, the repository `config` file is shared across all worktrees.
If the