Merge branch 'jn/doc-synopsis' into seen
Doc-mark-up modernization continues. * jn/doc-synopsis: doc: convert git worktree to synopsis style doc: convert git tag to synopsis style doc: convert git-stash.adoc to synopis style
Junio C Hamano
commit
788f2ccb12
|
|
@ -1,19 +1,28 @@
|
|||
stash.index::
|
||||
ifndef::git-stash[]
|
||||
:see-show: See the description of the 'show' command in linkgit:git-stash[1].
|
||||
endif::git-stash[]
|
||||
|
||||
ifdef::git-stash[]
|
||||
:see-show:
|
||||
endif::git-stash[]
|
||||
|
||||
`stash.index`::
|
||||
If this is set to true, `git stash apply` and `git stash pop` will
|
||||
behave as if `--index` was supplied. Defaults to false. See the
|
||||
descriptions in linkgit:git-stash[1].
|
||||
behave as if `--index` was supplied. Defaults to false.
|
||||
ifndef::git-stash[]
|
||||
See the descriptions in linkgit:git-stash[1].
|
||||
endif::git-stash[]
|
||||
|
||||
stash.showIncludeUntracked::
|
||||
`stash.showIncludeUntracked`::
|
||||
If this is set to true, the `git stash show` command will show
|
||||
the untracked files of a stash entry. Defaults to false. See
|
||||
the description of the 'show' command in linkgit:git-stash[1].
|
||||
the untracked files of a stash entry. Defaults to false. {see-show}
|
||||
|
||||
stash.showPatch::
|
||||
`stash.showPatch`::
|
||||
If this is set to true, the `git stash show` command without an
|
||||
option will show the stash entry in patch form. Defaults to false.
|
||||
See the description of the 'show' command in linkgit:git-stash[1].
|
||||
{see-show}
|
||||
|
||||
stash.showStat::
|
||||
`stash.showStat`::
|
||||
If this is set to true, the `git stash show` command without an
|
||||
option will show a diffstat of the stash entry. Defaults to true.
|
||||
See the description of the 'show' command in linkgit:git-stash[1].
|
||||
{see-show}
|
||||
|
|
|
|||
|
|
@ -1,17 +1,23 @@
|
|||
tag.forceSignAnnotated::
|
||||
`tag.forceSignAnnotated`::
|
||||
A boolean to specify whether annotated tags created should be GPG signed.
|
||||
If `--annotate` is specified on the command line, it takes
|
||||
precedence over this option.
|
||||
|
||||
tag.sort::
|
||||
This variable controls the sort ordering of tags when displayed by
|
||||
linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
|
||||
value of this variable will be used as the default.
|
||||
`tag.sort`::
|
||||
ifdef::git-tag[]
|
||||
This variable controls the sort ordering of tags when displayed by `git-tag`.
|
||||
endif::git-tag[]
|
||||
ifndef::git-tag[]
|
||||
This variable controls the sort ordering of tags when displayed by
|
||||
linkgit:git-tag[1].
|
||||
endif::git-tag[]
|
||||
Without the `--sort=<value>` option provided, the value of this variable will
|
||||
be used as the default.
|
||||
|
||||
tag.gpgSign::
|
||||
`tag.gpgSign`::
|
||||
A boolean to specify whether all tags should be GPG signed.
|
||||
Use of this option when running in an automated script can
|
||||
result in a large number of tags being signed. It is therefore
|
||||
convenient to use an agent to avoid typing your gpg passphrase
|
||||
convenient to use an agent to avoid typing your GPG passphrase
|
||||
several times. Note that this option doesn't affect tag signing
|
||||
behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options.
|
||||
behavior enabled by `-u <keyid>` or `--local-user=<keyid>` options.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
worktree.guessRemote::
|
||||
`worktree.guessRemote`::
|
||||
If no branch is specified and neither `-b` nor `-B` nor
|
||||
`--detach` is used, then `git worktree add` defaults to
|
||||
creating a new branch from HEAD. If `worktree.guessRemote` is
|
||||
|
|
@ -6,14 +6,14 @@ worktree.guessRemote::
|
|||
branch whose name uniquely matches the new branch name. If
|
||||
such a branch exists, it is checked out and set as "upstream"
|
||||
for the new branch. If no such match can be found, it falls
|
||||
back to creating a new branch from the current HEAD.
|
||||
back to creating a new branch from the current `HEAD`.
|
||||
|
||||
worktree.useRelativePaths::
|
||||
Link worktrees using relative paths (when "true") or absolute
|
||||
paths (when "false"). This is particularly useful for setups
|
||||
`worktree.useRelativePaths`::
|
||||
Link worktrees using relative paths (when "`true`") or absolute
|
||||
paths (when "`false`"). This is particularly useful for setups
|
||||
where the repository and worktrees may be moved between
|
||||
different locations or environments. Defaults to "false".
|
||||
different locations or environments. Defaults to "`false`".
|
||||
+
|
||||
Note that setting `worktree.useRelativePaths` to "true" implies enabling the
|
||||
Note that setting `worktree.useRelativePaths` to "`true`" implies enabling the
|
||||
`extensions.relativeWorktrees` config (see linkgit:git-config[1]),
|
||||
thus making it incompatible with older versions of Git.
|
||||
|
|
|
|||
|
|
@ -7,24 +7,24 @@ git-stash - Stash the changes in a dirty working directory away
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git stash' list [<log-options>]
|
||||
'git stash' show [-u | --include-untracked | --only-untracked] [<diff-options>] [<stash>]
|
||||
'git stash' drop [-q | --quiet] [<stash>]
|
||||
'git stash' pop [--index] [-q | --quiet] [<stash>]
|
||||
'git stash' apply [--index] [-q | --quiet] [<stash>]
|
||||
'git stash' branch <branchname> [<stash>]
|
||||
'git stash' [push [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
|
||||
[synopsis]
|
||||
git stash list [<log-options>]
|
||||
git stash show [-u | --include-untracked | --only-untracked] [<diff-options>] [<stash>]
|
||||
git stash drop [-q | --quiet] [<stash>]
|
||||
git stash pop [--index] [-q | --quiet] [<stash>]
|
||||
git stash apply [--index] [-q | --quiet] [<stash>]
|
||||
git stash branch <branchname> [<stash>]
|
||||
git stash [push [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
|
||||
[-u | --include-untracked] [-a | --all] [(-m | --message) <message>]
|
||||
[--pathspec-from-file=<file> [--pathspec-file-nul]]
|
||||
[--] [<pathspec>...]]
|
||||
'git stash' save [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
|
||||
[-u | --include-untracked] [-a | --all] [<message>]
|
||||
'git stash' clear
|
||||
'git stash' create [<message>]
|
||||
'git stash' store [(-m | --message) <message>] [-q | --quiet] <commit>
|
||||
'git stash' export (--print | --to-ref <ref>) [<stash>...]
|
||||
'git stash' import <commit>
|
||||
git stash save [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
|
||||
[-u | --include-untracked] [-a | --all] [<message>]
|
||||
git stash clear
|
||||
git stash create [<message>]
|
||||
git stash store [(-m | --message) <message>] [-q | --quiet] <commit>
|
||||
git stash export (--print | --to-ref <ref>) [<stash>...]
|
||||
git stash import <commit>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
|
@ -38,7 +38,7 @@ The modifications stashed away by this command can be listed with
|
|||
`git stash list`, inspected with `git stash show`, and restored
|
||||
(potentially on top of a different commit) with `git stash apply`.
|
||||
Calling `git stash` without any arguments is equivalent to `git stash push`.
|
||||
A stash is by default listed as "WIP on 'branchname' ...", but
|
||||
A stash is by default listed as "WIP on '<branchname>' ...", but
|
||||
you can give a more descriptive message on the command line when
|
||||
you create one.
|
||||
|
||||
|
|
@ -47,16 +47,16 @@ stashes are found in the reflog of this reference and can be named using
|
|||
the usual reflog syntax (e.g. `stash@{0}` is the most recently
|
||||
created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}`
|
||||
is also possible). Stashes may also be referenced by specifying just the
|
||||
stash index (e.g. the integer `n` is equivalent to `stash@{n}`).
|
||||
stash index (e.g. the integer `<n>` is equivalent to `stash@{<n>}`).
|
||||
|
||||
COMMANDS
|
||||
--------
|
||||
|
||||
push [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [(-m|--message) <message>] [--pathspec-from-file=<file> [--pathspec-file-nul]] [--] [<pathspec>...]::
|
||||
`push [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-u | --include-untracked] [ -a | --all] [-q | --quiet] [(-m|--message) <message>] [--pathspec-from-file=<file> [--pathspec-file-nul]] [--] [<pathspec>...]`::
|
||||
|
||||
Save your local modifications to a new 'stash entry' and roll them
|
||||
back to HEAD (in the working tree and in the index).
|
||||
The <message> part is optional and gives
|
||||
back to `HEAD` (in the working tree and in the index).
|
||||
The _<message>_ part is optional and gives
|
||||
the description along with the stashed state.
|
||||
+
|
||||
For quickly making a snapshot, you can omit "push". In this mode,
|
||||
|
|
@ -65,14 +65,14 @@ subcommand from making an unwanted stash entry. The two exceptions to this
|
|||
are `stash -p` which acts as alias for `stash push -p` and pathspec elements,
|
||||
which are allowed after a double hyphen `--` for disambiguation.
|
||||
|
||||
save [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]::
|
||||
`save [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-u | --include-untracked] [-a | --all] [-q | --quiet] [<message>]`::
|
||||
|
||||
This option is deprecated in favour of 'git stash push'. It
|
||||
differs from "stash push" in that it cannot take pathspec.
|
||||
Instead, all non-option arguments are concatenated to form the stash
|
||||
message.
|
||||
|
||||
list [<log-options>]::
|
||||
`list [<log-options>]`::
|
||||
|
||||
List the stash entries that you currently have. Each 'stash entry' is
|
||||
listed with its name (e.g. `stash@{0}` is the latest entry, `stash@{1}` is
|
||||
|
|
@ -88,7 +88,7 @@ stash@{1}: On master: 9cc0589... Add git-stash
|
|||
The command takes options applicable to the 'git log'
|
||||
command to control what is shown and how. See linkgit:git-log[1].
|
||||
|
||||
show [-u|--include-untracked|--only-untracked] [<diff-options>] [<stash>]::
|
||||
`show [-u | --include-untracked | --only-untracked] [<diff-options>] [<stash>]`::
|
||||
|
||||
Show the changes recorded in the stash entry as a diff between the
|
||||
stashed contents and the commit back when the stash entry was first
|
||||
|
|
@ -96,12 +96,12 @@ show [-u|--include-untracked|--only-untracked] [<diff-options>] [<stash>]::
|
|||
By default, the command shows the diffstat, but it will accept any
|
||||
format known to 'git diff' (e.g., `git stash show -p stash@{1}`
|
||||
to view the second most recent entry in patch form).
|
||||
If no `<diff-option>` is provided, the default behavior will be given
|
||||
If no _<diff-option>_ is provided, the default behavior will be given
|
||||
by the `stash.showStat`, and `stash.showPatch` config variables. You
|
||||
can also use `stash.showIncludeUntracked` to set whether
|
||||
`--include-untracked` is enabled by default.
|
||||
|
||||
pop [--index] [-q|--quiet] [<stash>]::
|
||||
`pop [--index] [-q | --quiet] [<stash>]`::
|
||||
|
||||
Remove a single stashed state from the stash list and apply it
|
||||
on top of the current working tree state, i.e., do the inverse
|
||||
|
|
@ -112,19 +112,19 @@ Applying the state can fail with conflicts; in this case, it is not
|
|||
removed from the stash list. You need to resolve the conflicts by hand
|
||||
and call `git stash drop` manually afterwards.
|
||||
|
||||
apply [--index] [-q|--quiet] [<stash>]::
|
||||
`apply [--index] [-q | --quiet] [<stash>]`::
|
||||
|
||||
Like `pop`, but do not remove the state from the stash list. Unlike `pop`,
|
||||
`<stash>` may be any commit that looks like a commit created by
|
||||
`stash push` or `stash create`.
|
||||
|
||||
branch <branchname> [<stash>]::
|
||||
`branch <branchname> [<stash>]`::
|
||||
|
||||
Creates and checks out a new branch named `<branchname>` starting from
|
||||
the commit at which the `<stash>` was originally created, applies the
|
||||
changes recorded in `<stash>` to the new working tree and index.
|
||||
If that succeeds, and `<stash>` is a reference of the form
|
||||
`stash@{<revision>}`, it then drops the `<stash>`.
|
||||
Creates and checks out a new branch named _<branchname>_ starting from
|
||||
the commit at which the _<stash>_ was originally created, applies the
|
||||
changes recorded in _<stash>_ to the new working tree and index.
|
||||
If that succeeds, and _<stash>_ is a reference of the form
|
||||
`stash@{<revision>}`, it then drops the _<stash>_.
|
||||
+
|
||||
This is useful if the branch on which you ran `git stash push` has
|
||||
changed enough that `git stash apply` fails due to conflicts. Since
|
||||
|
|
@ -132,54 +132,51 @@ the stash entry is applied on top of the commit that was HEAD at the
|
|||
time `git stash` was run, it restores the originally stashed state
|
||||
with no conflicts.
|
||||
|
||||
clear::
|
||||
`clear`::
|
||||
Remove all the stash entries. Note that those entries will then
|
||||
be subject to pruning, and may be impossible to recover (see
|
||||
'Examples' below for a possible strategy).
|
||||
|
||||
drop [-q|--quiet] [<stash>]::
|
||||
'EXAMPLES' below for a possible strategy).
|
||||
|
||||
`drop [-q | --quiet] [<stash>]`::
|
||||
Remove a single stash entry from the list of stash entries.
|
||||
|
||||
create::
|
||||
|
||||
`create`::
|
||||
Create a stash entry (which is a regular commit object) and
|
||||
return its object name, without storing it anywhere in the ref
|
||||
namespace.
|
||||
This is intended to be useful for scripts. It is probably not
|
||||
the command you want to use; see "push" above.
|
||||
|
||||
store::
|
||||
`store`::
|
||||
|
||||
Store a given stash created via 'git stash create' (which is a
|
||||
dangling merge commit) in the stash ref, updating the stash
|
||||
reflog. This is intended to be useful for scripts. It is
|
||||
probably not the command you want to use; see "push" above.
|
||||
|
||||
export ( --print | --to-ref <ref> ) [<stash>...]::
|
||||
`export ( --print | --to-ref <ref> ) [<stash>...]`::
|
||||
|
||||
Export the specified stashes, or all of them if none are specified, to
|
||||
a chain of commits which can be transferred using the normal fetch and
|
||||
push mechanisms, then imported using the `import` subcommand.
|
||||
|
||||
import <commit>::
|
||||
|
||||
`import <commit>`::
|
||||
Import the specified stashes from the specified commit, which must have been
|
||||
created by `export`, and add them to the list of stashes. To replace the
|
||||
existing stashes, use `clear` first.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
-a::
|
||||
--all::
|
||||
`-a`::
|
||||
`--all`::
|
||||
This option is only valid for `push` and `save` commands.
|
||||
+
|
||||
All ignored and untracked files are also stashed and then cleaned
|
||||
up with `git clean`.
|
||||
|
||||
-u::
|
||||
--include-untracked::
|
||||
--no-include-untracked::
|
||||
`-u`::
|
||||
`--include-untracked`::
|
||||
`--no-include-untracked`::
|
||||
When used with the `push` and `save` commands,
|
||||
all untracked files are also stashed and then cleaned up with
|
||||
`git clean`.
|
||||
|
|
@ -187,12 +184,12 @@ up with `git clean`.
|
|||
When used with the `show` command, show the untracked files in the stash
|
||||
entry as part of the diff.
|
||||
|
||||
--only-untracked::
|
||||
`--only-untracked`::
|
||||
This option is only valid for the `show` command.
|
||||
+
|
||||
Show only the untracked files in the stash entry as part of the diff.
|
||||
|
||||
--index::
|
||||
`--index`::
|
||||
This option is only valid for `pop` and `apply` commands.
|
||||
+
|
||||
Tries to reinstate not only the working tree's changes, but also
|
||||
|
|
@ -200,15 +197,15 @@ the index's ones. However, this can fail, when you have conflicts
|
|||
(which are stored in the index, where you therefore can no longer
|
||||
apply the changes as they were originally).
|
||||
|
||||
-k::
|
||||
--keep-index::
|
||||
--no-keep-index::
|
||||
`-k`::
|
||||
`--keep-index`::
|
||||
`--no-keep-index`::
|
||||
This option is only valid for `push` and `save` commands.
|
||||
+
|
||||
All changes already added to the index are left intact.
|
||||
|
||||
-p::
|
||||
--patch::
|
||||
`-p`::
|
||||
`--patch`::
|
||||
This option is only valid for `push` and `save` commands.
|
||||
+
|
||||
Interactively select hunks from the diff between HEAD and the
|
||||
|
|
@ -224,8 +221,8 @@ The `--patch` option implies `--keep-index`. You can use
|
|||
|
||||
include::diff-context-options.adoc[]
|
||||
|
||||
-S::
|
||||
--staged::
|
||||
`-S`::
|
||||
`--staged`::
|
||||
This option is only valid for `push` and `save` commands.
|
||||
+
|
||||
Stash only the changes that are currently staged. This is similar to
|
||||
|
|
@ -234,49 +231,49 @@ of current branch.
|
|||
+
|
||||
The `--patch` option has priority over this one.
|
||||
|
||||
--pathspec-from-file=<file>::
|
||||
`--pathspec-from-file=<file>`::
|
||||
This option is only valid for `push` command.
|
||||
+
|
||||
Pathspec is passed in `<file>` instead of commandline args. If
|
||||
`<file>` is exactly `-` then standard input is used. Pathspec
|
||||
Pathspec is passed in _<file>_ instead of commandline args. If
|
||||
_<file>_ is exactly `-` then standard input is used. Pathspec
|
||||
elements are separated by LF or CR/LF. Pathspec elements can be
|
||||
quoted as explained for the configuration variable `core.quotePath`
|
||||
(see linkgit:git-config[1]). See also `--pathspec-file-nul` and
|
||||
global `--literal-pathspecs`.
|
||||
|
||||
--pathspec-file-nul::
|
||||
`--pathspec-file-nul`::
|
||||
This option is only valid for `push` command.
|
||||
+
|
||||
Only meaningful with `--pathspec-from-file`. Pathspec elements are
|
||||
separated with NUL character and all other characters are taken
|
||||
literally (including newlines and quotes).
|
||||
|
||||
-q::
|
||||
--quiet::
|
||||
`-q`::
|
||||
`--quiet`::
|
||||
This option is only valid for `apply`, `drop`, `pop`, `push`,
|
||||
`save`, `store` commands.
|
||||
+
|
||||
Quiet, suppress feedback messages.
|
||||
|
||||
--print::
|
||||
`--print`::
|
||||
This option is only valid for the `export` command.
|
||||
+
|
||||
Create the chain of commits representing the exported stashes without
|
||||
storing it anywhere in the ref namespace and print the object ID to
|
||||
standard output. This is designed for scripts.
|
||||
|
||||
--to-ref::
|
||||
`--to-ref`::
|
||||
This option is only valid for the `export` command.
|
||||
+
|
||||
Create the chain of commits representing the exported stashes and store
|
||||
it to the specified ref.
|
||||
|
||||
\--::
|
||||
`--`::
|
||||
This option is only valid for `push` command.
|
||||
+
|
||||
Separates pathspec from options for disambiguation purposes.
|
||||
|
||||
<pathspec>...::
|
||||
`<pathspec>...`::
|
||||
This option is only valid for `push` command.
|
||||
+
|
||||
The new stash entry records the modified states only for the files
|
||||
|
|
@ -286,11 +283,11 @@ too, leaving files that do not match the pathspec intact.
|
|||
+
|
||||
For more details, see the 'pathspec' entry in linkgit:gitglossary[7].
|
||||
|
||||
<stash>::
|
||||
_<stash>_::
|
||||
This option is only valid for `apply`, `branch`, `drop`, `pop`,
|
||||
`show`, and `export` commands.
|
||||
+
|
||||
A reference of the form `stash@{<revision>}`. When no `<stash>` is
|
||||
A reference of the form `stash@{<revision>}`. When no _<stash>_ is
|
||||
given, the latest stash is assumed (that is, `stash@{0}`).
|
||||
|
||||
DISCUSSION
|
||||
|
|
@ -419,6 +416,7 @@ CONFIGURATION
|
|||
|
||||
include::includes/cmd-config-section-all.adoc[]
|
||||
|
||||
:git-stash: 1
|
||||
include::config/stash.adoc[]
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,21 +8,21 @@ git-tag - Create, list, delete or verify a tag object signed with GPG
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]
|
||||
[synopsis]
|
||||
git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]
|
||||
[(--trailer <token>[(=|:)<value>])...]
|
||||
<tagname> [<commit> | <object>]
|
||||
'git tag' -d <tagname>...
|
||||
'git tag' [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
|
||||
git tag -d <tagname>...
|
||||
git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
|
||||
[--points-at <object>] [--column[=<options>] | --no-column]
|
||||
[--create-reflog] [--sort=<key>] [--format=<format>]
|
||||
[--merged <commit>] [--no-merged <commit>] [<pattern>...]
|
||||
'git tag' -v [--format=<format>] <tagname>...
|
||||
git tag -v [--format=<format>] <tagname>...
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
Add a tag reference in `refs/tags/`, unless `-d/-l/-v` is given
|
||||
Add a tag reference in `refs/tags/`, unless `-d`/`-l`/`-v` is given
|
||||
to delete, list or verify tags.
|
||||
|
||||
Unless `-f` is given, the named tag must not yet exist.
|
||||
|
|
@ -58,129 +58,129 @@ lightweight tags by default.
|
|||
|
||||
OPTIONS
|
||||
-------
|
||||
-a::
|
||||
--annotate::
|
||||
`-a`::
|
||||
`--annotate`::
|
||||
Make an unsigned, annotated tag object
|
||||
|
||||
-s::
|
||||
--sign::
|
||||
`-s`::
|
||||
`--sign`::
|
||||
Make a GPG-signed tag, using the default e-mail address's key.
|
||||
The default behavior of tag GPG-signing is controlled by `tag.gpgSign`
|
||||
configuration variable if it exists, or disabled otherwise.
|
||||
See linkgit:git-config[1].
|
||||
|
||||
--no-sign::
|
||||
`--no-sign`::
|
||||
Override `tag.gpgSign` configuration variable that is
|
||||
set to force each and every tag to be signed.
|
||||
|
||||
-u <key-id>::
|
||||
--local-user=<key-id>::
|
||||
`-u <key-id>`::
|
||||
`--local-user=<key-id>`::
|
||||
Make a GPG-signed tag, using the given key.
|
||||
|
||||
-f::
|
||||
--force::
|
||||
`-f`::
|
||||
`--force`::
|
||||
Replace an existing tag with the given name (instead of failing)
|
||||
|
||||
-d::
|
||||
--delete::
|
||||
`-d`::
|
||||
`--delete`::
|
||||
Delete existing tags with the given names.
|
||||
|
||||
-v::
|
||||
--verify::
|
||||
`-v`::
|
||||
`--verify`::
|
||||
Verify the GPG signature of the given tag names.
|
||||
|
||||
-n<num>::
|
||||
<num> specifies how many lines from the annotation, if any,
|
||||
are printed when using -l. Implies `--list`.
|
||||
`-n<num>`::
|
||||
_<num>_ specifies how many lines from the annotation, if any,
|
||||
are printed when using `-l`. Implies `--list`.
|
||||
+
|
||||
The default is not to print any annotation lines.
|
||||
If no number is given to `-n`, only the first line is printed.
|
||||
If the tag is not annotated, the commit message is displayed instead.
|
||||
|
||||
-l::
|
||||
--list::
|
||||
`-l`::
|
||||
`--list`::
|
||||
List tags. With optional `<pattern>...`, e.g. `git tag --list
|
||||
'v-*'`, list only the tags that match the pattern(s).
|
||||
+
|
||||
Running "git tag" without arguments also lists all tags. The pattern
|
||||
is a shell wildcard (i.e., matched using fnmatch(3)). Multiple
|
||||
Running `git tag` without arguments also lists all tags. The pattern
|
||||
is a shell wildcard (i.e., matched using `fnmatch`(3)). Multiple
|
||||
patterns may be given; if any of them matches, the tag is shown.
|
||||
+
|
||||
This option is implicitly supplied if any other list-like option such
|
||||
as `--contains` is provided. See the documentation for each of those
|
||||
options for details.
|
||||
|
||||
--sort=<key>::
|
||||
`--sort=<key>`::
|
||||
Sort based on the key given. Prefix `-` to sort in
|
||||
descending order of the value. You may use the --sort=<key> option
|
||||
multiple times, in which case the last key becomes the primary
|
||||
key. Also supports "version:refname" or "v:refname" (tag
|
||||
names are treated as versions). The "version:refname" sort
|
||||
order can also be affected by the "versionsort.suffix"
|
||||
descending order of the value. You may use the `--sort=<key>` option
|
||||
multiple times, in which case the last _<key>_ becomes the primary
|
||||
key. Also supports "`version:refname`" or "`v:refname`" (tag
|
||||
names are treated as versions). The "`version:refname`" sort
|
||||
order can also be affected by the "`versionsort.suffix`"
|
||||
configuration variable.
|
||||
The keys supported are the same as those in `git for-each-ref`.
|
||||
Sort order defaults to the value configured for the `tag.sort`
|
||||
variable if it exists, or lexicographic order otherwise. See
|
||||
linkgit:git-config[1].
|
||||
|
||||
--color[=<when>]::
|
||||
`--color[=<when>]`::
|
||||
Respect any colors specified in the `--format` option. The
|
||||
`<when>` field must be one of `always`, `never`, or `auto` (if
|
||||
`<when>` is absent, behave as if `always` was given).
|
||||
_<when>_ field must be one of `always`, `never`, or `auto` (if
|
||||
_<when>_ is absent, behave as if `always` was given).
|
||||
|
||||
-i::
|
||||
--ignore-case::
|
||||
`-i`::
|
||||
`--ignore-case`::
|
||||
Sorting and filtering tags are case insensitive.
|
||||
|
||||
--omit-empty::
|
||||
`--omit-empty`::
|
||||
Do not print a newline after formatted refs where the format expands
|
||||
to the empty string.
|
||||
|
||||
--column[=<options>]::
|
||||
--no-column::
|
||||
`--column[=<options>]`::
|
||||
`--no-column`::
|
||||
Display tag listing in columns. See configuration variable
|
||||
`column.tag` for option syntax. `--column` and `--no-column`
|
||||
without options are equivalent to 'always' and 'never' respectively.
|
||||
without options are equivalent to `always` and `never` respectively.
|
||||
+
|
||||
This option is only applicable when listing tags without annotation lines.
|
||||
|
||||
--contains [<commit>]::
|
||||
Only list tags which contain the specified commit (HEAD if not
|
||||
`--contains [<commit>]`::
|
||||
Only list tags which contain _<commit>_ (`HEAD` if not
|
||||
specified). Implies `--list`.
|
||||
|
||||
--no-contains [<commit>]::
|
||||
Only list tags which don't contain the specified commit (HEAD if
|
||||
`--no-contains [<commit>]`::
|
||||
Only list tags which don't contain _<commit>_ (`HEAD` if
|
||||
not specified). Implies `--list`.
|
||||
|
||||
--merged [<commit>]::
|
||||
Only list tags whose commits are reachable from the specified
|
||||
commit (`HEAD` if not specified).
|
||||
`--merged [<commit>]`::
|
||||
Only list tags whose commits are reachable from
|
||||
_<commit>_ (`HEAD` if not specified).
|
||||
|
||||
--no-merged [<commit>]::
|
||||
Only list tags whose commits are not reachable from the specified
|
||||
commit (`HEAD` if not specified).
|
||||
`--no-merged [<commit>]`::
|
||||
Only list tags whose commits are not reachable from
|
||||
_<commit>_ (`HEAD` if not specified).
|
||||
|
||||
--points-at <object>::
|
||||
Only list tags of the given object (HEAD if not
|
||||
`--points-at [<object>]`::
|
||||
Only list tags of _<object>_ (`HEAD` if not
|
||||
specified). Implies `--list`.
|
||||
|
||||
-m <msg>::
|
||||
--message=<msg>::
|
||||
Use the given tag message (instead of prompting).
|
||||
`-m <msg>`::
|
||||
`--message=<msg>`::
|
||||
Use _<msg>_ (instead of prompting).
|
||||
If multiple `-m` options are given, their values are
|
||||
concatenated as separate paragraphs.
|
||||
Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
|
||||
is given.
|
||||
|
||||
-F <file>::
|
||||
--file=<file>::
|
||||
Take the tag message from the given file. Use '-' to
|
||||
`-F <file>`::
|
||||
`--file=<file>`::
|
||||
Take the tag message from _<file>_. Use `-` to
|
||||
read the message from the standard input.
|
||||
Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
|
||||
is given.
|
||||
|
||||
--trailer <token>[(=|:)<value>]::
|
||||
Specify a (<token>, <value>) pair that should be applied as a
|
||||
`--trailer <token>[(=|:)<value>]`::
|
||||
Specify a (_<token>_, _<value>_) pair that should be applied as a
|
||||
trailer. (e.g. `git tag --trailer "Custom-Key: value"`
|
||||
will add a "Custom-Key" trailer to the tag message.)
|
||||
The `trailer.*` configuration variables
|
||||
|
|
@ -190,46 +190,45 @@ This option is only applicable when listing tags without annotation lines.
|
|||
The trailers can be extracted in `git tag --list`, using
|
||||
`--format="%(trailers)"` placeholder.
|
||||
|
||||
-e::
|
||||
--edit::
|
||||
The message taken from file with `-F` and command line with
|
||||
`-m` are usually used as the tag message unmodified.
|
||||
This option lets you further edit the message taken from these sources.
|
||||
`-e`::
|
||||
`--edit`::
|
||||
Let further edit the message taken from file with `-F` and command line with
|
||||
`-m`.
|
||||
|
||||
--cleanup=<mode>::
|
||||
This option sets how the tag message is cleaned up.
|
||||
The '<mode>' can be one of 'verbatim', 'whitespace' and 'strip'. The
|
||||
'strip' mode is default. The 'verbatim' mode does not change message at
|
||||
all, 'whitespace' removes just leading/trailing whitespace lines and
|
||||
'strip' removes both whitespace and commentary.
|
||||
`--cleanup=<mode>`::
|
||||
Set how the tag message is cleaned up.
|
||||
The _<mode>_ can be one of `verbatim`, `whitespace` and `strip`. The
|
||||
`strip` mode is default. The `verbatim` mode does not change message at
|
||||
all, `whitespace` removes just leading/trailing whitespace lines and
|
||||
`strip` removes both whitespace and commentary.
|
||||
|
||||
--create-reflog::
|
||||
`--create-reflog`::
|
||||
Create a reflog for the tag. To globally enable reflogs for tags, see
|
||||
`core.logAllRefUpdates` in linkgit:git-config[1].
|
||||
The negated form `--no-create-reflog` only overrides an earlier
|
||||
`--create-reflog`, but currently does not negate the setting of
|
||||
`core.logAllRefUpdates`.
|
||||
|
||||
--format=<format>::
|
||||
`--format=<format>`::
|
||||
A string that interpolates `%(fieldname)` from a tag ref being shown
|
||||
and the object it points at. The format is the same as
|
||||
that of linkgit:git-for-each-ref[1]. When unspecified,
|
||||
defaults to `%(refname:strip=2)`.
|
||||
|
||||
<tagname>::
|
||||
_<tagname>_::
|
||||
The name of the tag to create, delete, or describe.
|
||||
The new tag name must pass all checks defined by
|
||||
linkgit:git-check-ref-format[1]. Some of these checks
|
||||
may restrict the characters allowed in a tag name.
|
||||
|
||||
<commit>::
|
||||
<object>::
|
||||
_<commit>_::
|
||||
_<object>_::
|
||||
The object that the new tag will refer to, usually a commit.
|
||||
Defaults to HEAD.
|
||||
Defaults to `HEAD`.
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
By default, 'git tag' in sign-with-default mode (-s) will use your
|
||||
By default, `git tag` in sign-with-default mode (`-s`) will use your
|
||||
committer identity (of the form `Your Name <your@email.address>`) to
|
||||
find a key. If you want to use a different default key, you can specify
|
||||
it in the repository configuration as follows:
|
||||
|
|
@ -252,7 +251,7 @@ On Re-tagging
|
|||
What should you do when you tag a wrong commit and you would
|
||||
want to re-tag?
|
||||
|
||||
If you never pushed anything out, just re-tag it. Use "-f" to
|
||||
If you never pushed anything out, just re-tag it. Use `-f` to
|
||||
replace the old one. And you're done.
|
||||
|
||||
But if you have pushed things out (or others could just read
|
||||
|
|
@ -268,12 +267,12 @@ the old tag. In that case you can do one of two things:
|
|||
|
||||
. The insane thing.
|
||||
You really want to call the new version "X" too, 'even though'
|
||||
others have already seen the old one. So just use 'git tag -f'
|
||||
others have already seen the old one. So just use `git tag -f`
|
||||
again, as if you hadn't already published the old one.
|
||||
|
||||
However, Git does *not* (and it should not) change tags behind
|
||||
users back. So if somebody already got the old tag, doing a
|
||||
'git pull' on your tree shouldn't just make them overwrite the old
|
||||
`git pull` on your tree shouldn't just make them overwrite the old
|
||||
one.
|
||||
|
||||
If somebody got a release tag from you, you cannot just change
|
||||
|
|
@ -325,7 +324,7 @@ private anchor point tags from the other person.
|
|||
|
||||
Often, "please pull" messages on the mailing list just provide
|
||||
two pieces of information: a repo URL and a branch name; this
|
||||
is designed to be easily cut&pasted at the end of a 'git fetch'
|
||||
is designed to be easily cut&pasted at the end of a `git fetch`
|
||||
command line:
|
||||
|
||||
------------
|
||||
|
|
@ -403,6 +402,14 @@ FILES
|
|||
user in an editor session will be available in this file, but
|
||||
may be overwritten by the next invocation of `git tag`.
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
||||
include::includes/cmd-config-section-all.adoc[]
|
||||
|
||||
:git-tag: 1
|
||||
include::config/tag.adoc[]
|
||||
|
||||
NOTES
|
||||
-----
|
||||
|
||||
|
|
|
|||
|
|
@ -8,16 +8,16 @@ git-worktree - Manage multiple working trees
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git worktree add' [-f] [--detach] [--checkout] [--lock [--reason <string>]]
|
||||
[--orphan] [(-b | -B) <new-branch>] <path> [<commit-ish>]
|
||||
'git worktree list' [-v | --porcelain [-z]]
|
||||
'git worktree lock' [--reason <string>] <worktree>
|
||||
'git worktree move' <worktree> <new-path>
|
||||
'git worktree prune' [-n] [-v] [--expire <expire>]
|
||||
'git worktree remove' [-f] <worktree>
|
||||
'git worktree repair' [<path>...]
|
||||
'git worktree unlock' <worktree>
|
||||
[synopsis]
|
||||
git worktree add [-f] [--detach] [--checkout] [--lock [--reason <string>]]
|
||||
[--orphan] [(-b | -B) <new-branch>] <path> [<commit-ish>]
|
||||
git worktree list [-v | --porcelain [-z]]
|
||||
git worktree lock [--reason <string>] <worktree>
|
||||
git worktree move <worktree> <new-path>
|
||||
git worktree prune [-n] [-v] [--expire <expire>]
|
||||
git worktree remove [-f] <worktree>
|
||||
git worktree repair [<path>...]
|
||||
git worktree unlock <worktree>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
|
@ -37,7 +37,7 @@ zero or more linked worktrees. When you are done with a linked worktree,
|
|||
remove it with `git worktree remove`.
|
||||
|
||||
In its simplest form, `git worktree add <path>` automatically creates a
|
||||
new branch whose name is the final component of `<path>`, which is
|
||||
new branch whose name is the final component of _<path>_, which is
|
||||
convenient if you plan to work on a new topic. For instance, `git
|
||||
worktree add ../hotfix` creates new branch `hotfix` and checks it out at
|
||||
path `../hotfix`. To instead work on an existing branch in a new worktree,
|
||||
|
|
@ -63,16 +63,16 @@ locked.
|
|||
|
||||
COMMANDS
|
||||
--------
|
||||
add <path> [<commit-ish>]::
|
||||
`add <path> [<commit-ish>]`::
|
||||
|
||||
Create a worktree at `<path>` and checkout `<commit-ish>` into it. The new worktree
|
||||
Create a worktree at _<path>_ and checkout _<commit-ish>_ into it. The new worktree
|
||||
is linked to the current repository, sharing everything except per-worktree
|
||||
files such as `HEAD`, `index`, etc. As a convenience, `<commit-ish>` may
|
||||
files such as `HEAD`, `index`, etc. As a convenience, _<commit-ish>_ may
|
||||
be a bare "`-`", which is synonymous with `@{-1}`.
|
||||
+
|
||||
If `<commit-ish>` is a branch name (call it `<branch>`) and is not found,
|
||||
If _<commit-ish>_ is a branch name (call it _<branch>_) and is not found,
|
||||
and neither `-b` nor `-B` nor `--detach` are used, but there does
|
||||
exist a tracking branch in exactly one remote (call it `<remote>`)
|
||||
exist a tracking branch in exactly one remote (call it _<remote>_)
|
||||
with a matching name, treat as equivalent to:
|
||||
+
|
||||
------------
|
||||
|
|
@ -84,32 +84,32 @@ existing worktrees - see <<EXAMPLES>>
|
|||
+
|
||||
If the branch exists in multiple remotes and one of them is named by
|
||||
the `checkout.defaultRemote` configuration variable, we'll use that
|
||||
one for the purposes of disambiguation, even if the `<branch>` isn't
|
||||
one for the purposes of disambiguation, even if the _<branch>_ isn't
|
||||
unique across all remotes. Set it to
|
||||
e.g. `checkout.defaultRemote=origin` to always checkout remote
|
||||
branches from there if `<branch>` is ambiguous but exists on the
|
||||
branches from there if _<branch>_ is ambiguous but exists on the
|
||||
`origin` remote. See also `checkout.defaultRemote` in
|
||||
linkgit:git-config[1].
|
||||
+
|
||||
If `<commit-ish>` is omitted and neither `-b` nor `-B` nor `--detach` used,
|
||||
If _<commit-ish>_ is omitted and neither `-b` nor `-B` nor `--detach` used,
|
||||
then, as a convenience, the new worktree is associated with a branch (call
|
||||
it `<branch>`) named after `$(basename <path>)`. If `<branch>` doesn't
|
||||
it _<branch>_) named after `$(basename <path>)`. If _<branch>_ doesn't
|
||||
exist, a new branch based on `HEAD` is automatically created as if
|
||||
`-b <branch>` was given. If `<branch>` does exist, it will be checked out
|
||||
`-b <branch>` was given. If _<branch>_ does exist, it will be checked out
|
||||
in the new worktree, if it's not checked out anywhere else, otherwise the
|
||||
command will refuse to create the worktree (unless `--force` is used).
|
||||
+
|
||||
If `<commit-ish>` is omitted, neither `--detach`, or `--orphan` is
|
||||
If _<commit-ish>_ is omitted, neither `--detach`, or `--orphan` is
|
||||
used, and there are no valid local branches (or remote branches if
|
||||
`--guess-remote` is specified) then, as a convenience, the new worktree is
|
||||
associated with a new unborn branch named `<branch>` (after
|
||||
associated with a new unborn branch named _<branch>_ (after
|
||||
`$(basename <path>)` if neither `-b` or `-B` is used) as if `--orphan` was
|
||||
passed to the command. In the event the repository has a remote and
|
||||
`--guess-remote` is used, but no remote or local branches exist, then the
|
||||
command fails with a warning reminding the user to fetch from their remote
|
||||
first (or override by using `-f/--force`).
|
||||
|
||||
list::
|
||||
`list`::
|
||||
|
||||
List details of each worktree. The main worktree is listed first,
|
||||
followed by each of the linked worktrees. The output details include
|
||||
|
|
@ -118,32 +118,32 @@ branch currently checked out (or "detached HEAD" if none), "locked" if
|
|||
the worktree is locked, "prunable" if the worktree can be pruned by the
|
||||
`prune` command.
|
||||
|
||||
lock::
|
||||
`lock`::
|
||||
|
||||
If a worktree is on a portable device or network share which is not always
|
||||
mounted, lock it to prevent its administrative files from being pruned
|
||||
automatically. This also prevents it from being moved or deleted.
|
||||
Optionally, specify a reason for the lock with `--reason`.
|
||||
|
||||
move::
|
||||
`move`::
|
||||
|
||||
Move a worktree to a new location. Note that the main worktree or linked
|
||||
worktrees containing submodules cannot be moved with this command. (The
|
||||
`git worktree repair` command, however, can reestablish the connection
|
||||
with linked worktrees if you move the main worktree manually.)
|
||||
|
||||
prune::
|
||||
`prune`::
|
||||
|
||||
Prune worktree information in `$GIT_DIR/worktrees`.
|
||||
|
||||
remove::
|
||||
`remove`::
|
||||
|
||||
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 [<path>...]`::
|
||||
|
||||
Repair worktree administrative files, if possible, if they have become
|
||||
corrupted or outdated due to external factors.
|
||||
|
|
@ -157,72 +157,72 @@ 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
|
||||
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>`
|
||||
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`::
|
||||
|
||||
Unlock a worktree, allowing it to be pruned, moved or deleted.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
-f::
|
||||
--force::
|
||||
`-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
|
||||
_<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`
|
||||
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`.
|
||||
`-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>`.
|
||||
exists. `-B` overrides this safeguard, resetting _<new-branch>_ to
|
||||
_<commit-ish>_.
|
||||
|
||||
-d::
|
||||
--detach::
|
||||
`-d`::
|
||||
`--detach`::
|
||||
With `add`, detach `HEAD` in the new worktree. See "DETACHED HEAD"
|
||||
in linkgit:git-checkout[1].
|
||||
|
||||
--checkout::
|
||||
--no-checkout::
|
||||
By default, `add` checks out `<commit-ish>`, however, `--no-checkout` can
|
||||
`--checkout`::
|
||||
`--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].
|
||||
|
||||
--guess-remote::
|
||||
--no-guess-remote::
|
||||
With `worktree add <path>`, without `<commit-ish>`, instead
|
||||
`--guess-remote`::
|
||||
`--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>`,
|
||||
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.
|
||||
|
||||
--relative-paths::
|
||||
--no-relative-paths::
|
||||
`--relative-paths`::
|
||||
`--no-relative-paths`::
|
||||
Link worktrees using relative paths or absolute paths (default).
|
||||
Overrides the `worktree.useRelativePaths` config option, see
|
||||
linkgit:git-config[1].
|
||||
|
|
@ -230,60 +230,60 @@ This can also be set up as the default behaviour by using the
|
|||
With `repair`, the linking files will be updated if there's an absolute/relative
|
||||
mismatch, even if the links are correct.
|
||||
|
||||
--track::
|
||||
--no-track::
|
||||
When creating a new branch, if `<commit-ish>` is a branch,
|
||||
`--track`::
|
||||
`--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
|
||||
default if _<commit-ish>_ is a remote-tracking branch. See
|
||||
`--track` in linkgit:git-branch[1] for details.
|
||||
|
||||
--lock::
|
||||
`--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::
|
||||
`-n`::
|
||||
`--dry-run`::
|
||||
With `prune`, do not remove anything; just report what it would
|
||||
remove.
|
||||
|
||||
--orphan::
|
||||
`--orphan`::
|
||||
With `add`, make the new worktree and index empty, associating
|
||||
the worktree with a new unborn branch named `<new-branch>`.
|
||||
the worktree with a new unborn branch named _<new-branch>_.
|
||||
|
||||
--porcelain::
|
||||
`--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
|
||||
`-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::
|
||||
`-q`::
|
||||
`--quiet`::
|
||||
With `add`, suppress feedback messages.
|
||||
|
||||
-v::
|
||||
--verbose::
|
||||
`-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>`.
|
||||
`--expire <time>`::
|
||||
With `prune`, only expire unused worktrees older than _<time>_.
|
||||
+
|
||||
With `list`, annotate missing worktrees as prunable if they are older than
|
||||
`<time>`.
|
||||
_<time>_.
|
||||
|
||||
--reason <string>::
|
||||
`--reason <string>`::
|
||||
With `lock` or with `add --lock`, an explanation why the worktree
|
||||
is locked.
|
||||
|
||||
<worktree>::
|
||||
_<worktree>_::
|
||||
Worktrees can be identified by path, either relative or absolute.
|
||||
+
|
||||
If the last path components in the worktree's path is unique among
|
||||
|
|
@ -537,6 +537,13 @@ git --git-dir=bunny.git worktree add some-branch
|
|||
git --git-dir=bunny.git worktree add another-branch
|
||||
------------
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
||||
include::includes/cmd-config-section-all.adoc[]
|
||||
|
||||
include::config/worktree.adoc[]
|
||||
|
||||
BUGS
|
||||
----
|
||||
Multiple checkout in general is still experimental, and the support
|
||||
|
|
|
|||
Loading…
Reference in New Issue