diff --git a/GIT-VERSION-FILE b/GIT-VERSION-FILE
index 4e5b821cfca35c290702d1841a05637fe5f964fc..2c067bed21e7a387bd4745ef013bd369c8e21cbc 100644
--- a/GIT-VERSION-FILE
+++ b/GIT-VERSION-FILE
@@ -1 +1 @@
-GIT_VERSION = 2.12.1.431.g53026fc228
+GIT_VERSION = 2.21.0
diff --git a/en/cmds-ancillaryinterrogators.txt b/en/cmds-ancillaryinterrogators.txt
index f1c167b4dbb16121b7cc0f770933023fa994f478..019325934ab77f5c5dd842d88f349cf9cae6c20f 100644
--- a/en/cmds-ancillaryinterrogators.txt
+++ b/en/cmds-ancillaryinterrogators.txt
@@ -4,9 +4,6 @@ linkgit:git-annotate[1]::
linkgit:git-blame[1]::
Show what revision and author last modified each line of a file.
-linkgit:git-cherry[1]::
- Find commits yet to be applied to upstream.
-
linkgit:git-count-objects[1]::
Count unpacked number of objects and their disk consumption.
@@ -16,9 +13,6 @@ linkgit:git-difftool[1]::
linkgit:git-fsck[1]::
Verifies the connectivity and validity of the objects in the database.
-linkgit:git-get-tar-commit-id[1]::
- Extract commit ID from an archive created using git-archive.
-
linkgit:git-help[1]::
Display help information about Git.
@@ -31,9 +25,6 @@ linkgit:git-merge-tree[1]::
linkgit:git-rerere[1]::
Reuse recorded resolution of conflicted merges.
-linkgit:git-rev-parse[1]::
- Pick out and massage parameters.
-
linkgit:git-show-branch[1]::
Show branches and their commits.
diff --git a/en/cmds-foreignscminterface.txt b/en/cmds-foreignscminterface.txt
index 05892e3e83d7924d414767a0cad1f7c049636efc..29236a05844b79c18c48f461012a63f680356da7 100644
--- a/en/cmds-foreignscminterface.txt
+++ b/en/cmds-foreignscminterface.txt
@@ -1,5 +1,5 @@
linkgit:git-archimport[1]::
- Import an Arch repository into Git.
+ Import a GNU Arch repository into Git.
linkgit:git-cvsexportcommit[1]::
Export a single commit to a CVS checkout.
diff --git a/en/cmds-mainporcelain.txt b/en/cmds-mainporcelain.txt
index fc00dc48e382202e8ec1a50ac07e6269ecd49c13..e41a5e12dd7ac6de63f0d4bfd113a50e55cc0db5 100644
--- a/en/cmds-mainporcelain.txt
+++ b/en/cmds-mainporcelain.txt
@@ -76,6 +76,9 @@ linkgit:git-pull[1]::
linkgit:git-push[1]::
Update remote refs along with associated objects.
+linkgit:git-range-diff[1]::
+ Compare two commit ranges (e.g. two versions of a branch).
+
linkgit:git-rebase[1]::
Reapply commits on top of another base tip.
diff --git a/en/cmds-plumbinginterrogators.txt b/en/cmds-plumbinginterrogators.txt
index a6a76c475e6525028e5514fa33f9849b7e0d6554..1b5c8dc061c7a3c06ac6846e7a0a05027ca12879 100644
--- a/en/cmds-plumbinginterrogators.txt
+++ b/en/cmds-plumbinginterrogators.txt
@@ -1,6 +1,9 @@
linkgit:git-cat-file[1]::
Provide content or type and size information for repository objects.
+linkgit:git-cherry[1]::
+ Find commits yet to be applied to upstream.
+
linkgit:git-diff-files[1]::
Compares files in the working tree and the index.
@@ -13,6 +16,9 @@ linkgit:git-diff-tree[1]::
linkgit:git-for-each-ref[1]::
Output information on each ref.
+linkgit:git-get-tar-commit-id[1]::
+ Extract commit ID from an archive created using git-archive.
+
linkgit:git-ls-files[1]::
Show information about files in the index and the working tree.
@@ -34,6 +40,9 @@ linkgit:git-pack-redundant[1]::
linkgit:git-rev-list[1]::
Lists commit objects in reverse chronological order.
+linkgit:git-rev-parse[1]::
+ Pick out and massage parameters.
+
linkgit:git-show-index[1]::
Show packed archive index.
diff --git a/en/cmds-plumbingmanipulators.txt b/en/cmds-plumbingmanipulators.txt
index ef699b400d2c0ac1fdc0e788f7d85c50d0361432..b6840534d80327b7de38e91dcbf556f3304f2ccc 100644
--- a/en/cmds-plumbingmanipulators.txt
+++ b/en/cmds-plumbingmanipulators.txt
@@ -4,6 +4,9 @@ linkgit:git-apply[1]::
linkgit:git-checkout-index[1]::
Copy files from the index to the working tree.
+linkgit:git-commit-graph[1]::
+ Write and verify Git commit-graph files.
+
linkgit:git-commit-tree[1]::
Create a new commit object.
@@ -25,6 +28,9 @@ linkgit:git-mktag[1]::
linkgit:git-mktree[1]::
Build a tree-object from ls-tree formatted text.
+linkgit:git-multi-pack-index[1]::
+ Write and verify multi-pack-indexes.
+
linkgit:git-pack-objects[1]::
Create a packed archive of objects.
diff --git a/en/config.txt b/en/config.txt
index 0d8df5a9f95b9550d34d000027f2974ff93f4de6..d87846faa6c3ffad7cba97fe7348ef97e0112899 100644
--- a/en/config.txt
+++ b/en/config.txt
@@ -2,8 +2,9 @@ CONFIGURATION FILE
------------------
The Git configuration file contains a number of variables that affect
-the Git commands' behavior. The `.git/config` file in each repository
-is used to store the configuration for that repository, and
+the Git commands' behavior. The files `.git/config` and optionally
+`config.worktree` (see `extensions.worktreeConfig` below) in each
+repository are used to store the configuration for that repository, and
`$HOME/.gitconfig` is used to store a per-user configuration as
fallback values for the `.git/config` file. The file `/etc/gitconfig`
can be used to store a system-wide default configuration.
@@ -41,11 +42,13 @@ in the section header, like in the example below:
--------
Subsection names are case sensitive and can contain any characters except
-newline (doublequote `"` and backslash can be included by escaping them
-as `\"` and `\\`, respectively). Section headers cannot span multiple
-lines. Variables may belong directly to a section or to a given subsection.
-You can have `[section]` if you have `[section "subsection"]`, but you
-don't need to.
+newline and the null byte. Doublequote `"` and backslash can be included
+by escaping them as `\"` and `\\`, respectively. Backslashes preceding
+other characters are dropped when reading; for example, `\t` is read as
+`t` and `\0` is read as `0` Section headers cannot span multiple lines.
+Variables may belong directly to a section or to a given subsection. You
+can have `[section]` if you have `[section "subsection"]`, but you don't
+need to.
There is also a deprecated `[section.subsection]` syntax. With this
syntax, the subsection name is converted to lower-case and is also
@@ -79,14 +82,20 @@ escape sequences) are invalid.
Includes
~~~~~~~~
+The `include` and `includeIf` sections allow you to include config
+directives from another source. These sections behave identically to
+each other with the exception that `includeIf` sections may be ignored
+if their condition does not evaluate to true; see "Conditional includes"
+below.
+
You can include a config file from another by setting the special
-`include.path` variable to the name of the file to be included. The
-variable takes a pathname as its value, and is subject to tilde
-expansion. `include.path` can be given multiple times.
+`include.path` (or `includeIf.*.path`) variable to the name of the file
+to be included. The variable takes a pathname as its value, and is
+subject to tilde expansion. These variables can be given multiple times.
-The included file is expanded immediately, as if its contents had been
-found at the location of the include directive. If the value of the
-`include.path` variable is a relative path, the path is considered to
+The contents of the included file are inserted immediately, as if they
+had been found at the location of the include directive. If the value of the
+variable is a relative path, the path is considered to
be relative to the configuration file in which the include directive
was found. See below for examples.
@@ -95,8 +104,7 @@ Conditional includes
You can include a config file from another conditionally by setting a
`includeIf.<condition>.path` variable to the name of the file to be
-included. The variable's value is treated the same way as
-`include.path`. `includeIf.<condition>.path` can be given multiple times.
+included.
The condition starts with a keyword followed by a colon and some data
whose format and meaning depends on the keyword. Supported keywords
@@ -140,6 +148,16 @@ A few more notes on matching via `gitdir` and `gitdir/i`:
* Symlinks in `$GIT_DIR` are not resolved before matching.
+ * Both the symlink & realpath versions of paths will be matched
+ outside of `$GIT_DIR`. E.g. if ~/git is a symlink to
+ /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git`
+ will match.
++
+This was not the case in the initial release of this feature in
+v2.13.0, which only matched the realpath version. Configuration that
+wants to be compatible with the initial release of this feature needs
+to either specify only the realpath version, or both versions.
+
* Note that "../" is not special and will match literally, which is
unlikely what you want.
@@ -167,8 +185,8 @@ Example
[include]
path = /path/to/foo.inc ; include by absolute path
- path = foo ; expand "foo" relative to the current file
- path = ~/foo ; expand "foo" in your `$HOME` directory
+ path = foo.inc ; find "foo.inc" relative to the current file
+ path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
; include if $GIT_DIR is /path/to/foo/.git
[includeIf "gitdir:/path/to/foo/.git"]
@@ -182,6 +200,12 @@ Example
[includeIf "gitdir:~/to/group/"]
path = /path/to/foo.inc
+ ; relative paths are always relative to the including
+ ; file (if the condition is true); their location is not
+ ; affected by the condition
+ [includeIf "gitdir:/path/to/group/"]
+ path = foo.inc
+
Values
~~~~~~
@@ -195,15 +219,15 @@ boolean::
synonyms are accepted for 'true' and 'false'; these are all
case-insensitive.
- true;; Boolean true can be spelled as `yes`, `on`, `true`,
- or `1`. Also, a variable defined without `= <value>`
+ true;; Boolean true literals are `yes`, `on`, `true`,
+ and `1`. Also, a variable defined without `= <value>`
is taken as true.
- false;; Boolean false can be spelled as `no`, `off`,
- `false`, or `0`.
+ false;; Boolean false literals are `no`, `off`, `false`,
+ `0` and the empty string.
+
-When converting value to the canonical form using `--bool` type
-specifier; 'git config' will ensure that the output is "true" or
+When converting a value to its canonical form using the `--type=bool` type
+specifier, 'git config' will ensure that the output is "true" or
"false" (spelled in lowercase).
integer::
@@ -264,3015 +288,152 @@ inventing new variables for use in your own tool, make sure their
names do not conflict with those that are used by Git itself and
other popular tools, and describe them in your documentation.
+include::config/advice.txt[]
-advice.*::
- These variables control various optional help messages designed to
- aid new users. All 'advice.*' variables default to 'true', and you
- can tell Git that you do not need help by setting these to 'false':
-+
---
- pushUpdateRejected::
- Set this variable to 'false' if you want to disable
- 'pushNonFFCurrent',
- 'pushNonFFMatching', 'pushAlreadyExists',
- 'pushFetchFirst', and 'pushNeedsForce'
- simultaneously.
- pushNonFFCurrent::
- Advice shown when linkgit:git-push[1] fails due to a
- non-fast-forward update to the current branch.
- pushNonFFMatching::
- Advice shown when you ran linkgit:git-push[1] and pushed
- 'matching refs' explicitly (i.e. you used ':', or
- specified a refspec that isn't your current branch) and
- it resulted in a non-fast-forward error.
- pushAlreadyExists::
- Shown when linkgit:git-push[1] rejects an update that
- does not qualify for fast-forwarding (e.g., a tag.)
- pushFetchFirst::
- Shown when linkgit:git-push[1] rejects an update that
- tries to overwrite a remote ref that points at an
- object we do not have.
- pushNeedsForce::
- Shown when linkgit:git-push[1] rejects an update that
- tries to overwrite a remote ref that points at an
- object that is not a commit-ish, or make the remote
- ref point at an object that is not a commit-ish.
- statusHints::
- Show directions on how to proceed from the current
- state in the output of linkgit:git-status[1], in
- the template shown when writing commit messages in
- linkgit:git-commit[1], and in the help message shown
- by linkgit:git-checkout[1] when switching branch.
- statusUoption::
- Advise to consider using the `-u` option to linkgit:git-status[1]
- when the command takes more than 2 seconds to enumerate untracked
- files.
- commitBeforeMerge::
- Advice shown when linkgit:git-merge[1] refuses to
- merge to avoid overwriting local changes.
- resolveConflict::
- Advice shown by various commands when conflicts
- prevent the operation from being performed.
- implicitIdentity::
- Advice on how to set your identity configuration when
- your information is guessed from the system username and
- domain name.
- detachedHead::
- Advice shown when you used linkgit:git-checkout[1] to
- move to the detach HEAD state, to instruct how to create
- a local branch after the fact.
- amWorkDir::
- Advice that shows the location of the patch file when
- linkgit:git-am[1] fails to apply it.
- rmHints::
- In case of failure in the output of linkgit:git-rm[1],
- show directions on how to proceed from the current state.
---
-
-core.fileMode::
- Tells Git if the executable bit of files in the working tree
- is to be honored.
-+
-Some filesystems lose the executable bit when a file that is
-marked as executable is checked out, or checks out an
-non-executable file with executable bit on.
-linkgit:git-clone[1] or linkgit:git-init[1] probe the filesystem
-to see if it handles the executable bit correctly
-and this variable is automatically set as necessary.
-+
-A repository, however, may be on a filesystem that handles
-the filemode correctly, and this variable is set to 'true'
-when created, but later may be made accessible from another
-environment that loses the filemode (e.g. exporting ext4 via
-CIFS mount, visiting a Cygwin created repository with
-Git for Windows or Eclipse).
-In such a case it may be necessary to set this variable to 'false'.
-See linkgit:git-update-index[1].
-+
-The default is true (when core.filemode is not specified in the config file).
-
-core.hideDotFiles::
- (Windows-only) If true, mark newly-created directories and files whose
- name starts with a dot as hidden. If 'dotGitOnly', only the `.git/`
- directory is hidden, but no other files starting with a dot. The
- default mode is 'dotGitOnly'.
-
-core.ignoreCase::
- If true, this option enables various workarounds to enable
- Git to work better on filesystems that are not case sensitive,
- like FAT. For example, if a directory listing finds
- "makefile" when Git expects "Makefile", Git will assume
- it is really the same file, and continue to remember it as
- "Makefile".
-+
-The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]
-will probe and set core.ignoreCase true if appropriate when the repository
-is created.
-
-core.precomposeUnicode::
- This option is only used by Mac OS implementation of Git.
- When core.precomposeUnicode=true, Git reverts the unicode decomposition
- of filenames done by Mac OS. This is useful when sharing a repository
- between Mac OS and Linux or Windows.
- (Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7).
- When false, file names are handled fully transparent by Git,
- which is backward compatible with older versions of Git.
-
-core.protectHFS::
- If set to true, do not allow checkout of paths that would
- be considered equivalent to `.git` on an HFS+ filesystem.
- Defaults to `true` on Mac OS, and `false` elsewhere.
-
-core.protectNTFS::
- If set to true, do not allow checkout of paths that would
- cause problems with the NTFS filesystem, e.g. conflict with
- 8.3 "short" names.
- Defaults to `true` on Windows, and `false` elsewhere.
-
-core.trustctime::
- If false, the ctime differences between the index and the
- working tree are ignored; useful when the inode change time
- is regularly modified by something outside Git (file system
- crawlers and some backup systems).
- See linkgit:git-update-index[1]. True by default.
-
-core.splitIndex::
- If true, the split-index feature of the index will be used.
- See linkgit:git-update-index[1]. False by default.
-
-core.untrackedCache::
- Determines what to do about the untracked cache feature of the
- index. It will be kept, if this variable is unset or set to
- `keep`. It will automatically be added if set to `true`. And
- it will automatically be removed, if set to `false`. Before
- setting it to `true`, you should check that mtime is working
- properly on your system.
- See linkgit:git-update-index[1]. `keep` by default.
-
-core.checkStat::
- Determines which stat fields to match between the index
- and work tree. The user can set this to 'default' or
- 'minimal'. Default (or explicitly 'default'), is to check
- all fields, including the sub-second part of mtime and ctime.
-
-core.quotePath::
- Commands that output paths (e.g. 'ls-files', 'diff'), will
- quote "unusual" characters in the pathname by enclosing the
- pathname in double-quotes and escaping those characters with
- backslashes in the same way C escapes control characters (e.g.
- `\t` for TAB, `\n` for LF, `\\` for backslash) or bytes with
- values larger than 0x80 (e.g. octal `\302\265` for "micro" in
- UTF-8). If this variable is set to false, bytes higher than
- 0x80 are not considered "unusual" any more. Double-quotes,
- backslash and control characters are always escaped regardless
- of the setting of this variable. A simple space character is
- not considered "unusual". Many commands can output pathnames
- completely verbatim using the `-z` option. The default value
- is true.
-
-core.eol::
- Sets the line ending type to use in the working directory for
- files that have the `text` property set when core.autocrlf is false.
- Alternatives are 'lf', 'crlf' and 'native', which uses the platform's
- native line ending. The default value is `native`. See
- linkgit:gitattributes[5] for more information on end-of-line
- conversion.
-
-core.safecrlf::
- If true, makes Git check if converting `CRLF` is reversible when
- end-of-line conversion is active. Git will verify if a command
- modifies a file in the work tree either directly or indirectly.
- For example, committing a file followed by checking out the
- same file should yield the original file in the work tree. If
- this is not the case for the current setting of
- `core.autocrlf`, Git will reject the file. The variable can
- be set to "warn", in which case Git will only warn about an
- irreversible conversion but continue the operation.
-+
-CRLF conversion bears a slight chance of corrupting data.
-When it is enabled, Git will convert CRLF to LF during commit and LF to
-CRLF during checkout. A file that contains a mixture of LF and
-CRLF before the commit cannot be recreated by Git. For text
-files this is the right thing to do: it corrects line endings
-such that we have only LF line endings in the repository.
-But for binary files that are accidentally classified as text the
-conversion can corrupt data.
-+
-If you recognize such corruption early you can easily fix it by
-setting the conversion type explicitly in .gitattributes. Right
-after committing you still have the original file in your work
-tree and this file is not yet corrupted. You can explicitly tell
-Git that this file is binary and Git will handle the file
-appropriately.
-+
-Unfortunately, the desired effect of cleaning up text files with
-mixed line endings and the undesired effect of corrupting binary
-files cannot be distinguished. In both cases CRLFs are removed
-in an irreversible way. For text files this is the right thing
-to do because CRLFs are line endings, while for binary files
-converting CRLFs corrupts data.
-+
-Note, this safety check does not mean that a checkout will generate a
-file identical to the original file for a different setting of
-`core.eol` and `core.autocrlf`, but only for the current one. For
-example, a text file with `LF` would be accepted with `core.eol=lf`
-and could later be checked out with `core.eol=crlf`, in which case the
-resulting file would contain `CRLF`, although the original file
-contained `LF`. However, in both work trees the line endings would be
-consistent, that is either all `LF` or all `CRLF`, but never mixed. A
-file with mixed line endings would be reported by the `core.safecrlf`
-mechanism.
-
-core.autocrlf::
- Setting this variable to "true" is the same as setting
- the `text` attribute to "auto" on all files and core.eol to "crlf".
- Set to true if you want to have `CRLF` line endings in your
- working directory and the repository has LF line endings.
- This variable can be set to 'input',
- in which case no output conversion is performed.
-
-core.symlinks::
- If false, symbolic links are checked out as small plain files that
- contain the link text. linkgit:git-update-index[1] and
- linkgit:git-add[1] will not change the recorded type to regular
- file. Useful on filesystems like FAT that do not support
- symbolic links.
-+
-The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]
-will probe and set core.symlinks false if appropriate when the repository
-is created.
-
-core.gitProxy::
- A "proxy command" to execute (as 'command host port') instead
- of establishing direct connection to the remote server when
- using the Git protocol for fetching. If the variable value is
- in the "COMMAND for DOMAIN" format, the command is applied only
- on hostnames ending with the specified domain string. This variable
- may be set multiple times and is matched in the given order;
- the first match wins.
-+
-Can be overridden by the `GIT_PROXY_COMMAND` environment variable
-(which always applies universally, without the special "for"
-handling).
-+
-The special string `none` can be used as the proxy command to
-specify that no proxy be used for a given domain pattern.
-This is useful for excluding servers inside a firewall from
-proxy use, while defaulting to a common proxy for external domains.
-
-core.sshCommand::
- If this variable is set, `git fetch` and `git push` will
- use the specified command instead of `ssh` when they need to
- connect to a remote system. The command is in the same form as
- the `GIT_SSH_COMMAND` environment variable and is overridden
- when the environment variable is set.
-
-core.ignoreStat::
- If true, Git will avoid using lstat() calls to detect if files have
- changed by setting the "assume-unchanged" bit for those tracked files
- which it has updated identically in both the index and working tree.
-+
-When files are modified outside of Git, the user will need to stage
-the modified files explicitly (e.g. see 'Examples' section in
-linkgit:git-update-index[1]).
-Git will not normally detect changes to those files.
-+
-This is useful on systems where lstat() calls are very slow, such as
-CIFS/Microsoft Windows.
-+
-False by default.
-
-core.preferSymlinkRefs::
- Instead of the default "symref" format for HEAD
- and other symbolic reference files, use symbolic links.
- This is sometimes needed to work with old scripts that
- expect HEAD to be a symbolic link.
-
-core.bare::
- If true this repository is assumed to be 'bare' and has no
- working directory associated with it. If this is the case a
- number of commands that require a working directory will be
- disabled, such as linkgit:git-add[1] or linkgit:git-merge[1].
-+
-This setting is automatically guessed by linkgit:git-clone[1] or
-linkgit:git-init[1] when the repository was created. By default a
-repository that ends in "/.git" is assumed to be not bare (bare =
-false), while all other repositories are assumed to be bare (bare
-= true).
-
-core.worktree::
- Set the path to the root of the working tree.
- If `GIT_COMMON_DIR` environment variable is set, core.worktree
- is ignored and not used for determining the root of working tree.
- This can be overridden by the `GIT_WORK_TREE` environment
- variable and the `--work-tree` command-line option.
- The value can be an absolute path or relative to the path to
- the .git directory, which is either specified by --git-dir
- or GIT_DIR, or automatically discovered.
- If --git-dir or GIT_DIR is specified but none of
- --work-tree, GIT_WORK_TREE and core.worktree is specified,
- the current working directory is regarded as the top level
- of your working tree.
-+
-Note that this variable is honored even when set in a configuration
-file in a ".git" subdirectory of a directory and its value differs
-from the latter directory (e.g. "/path/to/.git/config" has
-core.worktree set to "/different/path"), which is most likely a
-misconfiguration. Running Git commands in the "/path/to" directory will
-still use "/different/path" as the root of the work tree and can cause
-confusion unless you know what you are doing (e.g. you are creating a
-read-only snapshot of the same index to a location different from the
-repository's usual working tree).
-
-core.logAllRefUpdates::
- Enable the reflog. Updates to a ref <ref> is logged to the file
- "`$GIT_DIR/logs/<ref>`", by appending the new and old
- SHA-1, the date/time and the reason of the update, but
- only when the file exists. If this configuration
- variable is set to `true`, missing "`$GIT_DIR/logs/<ref>`"
- file is automatically created for branch heads (i.e. under
- `refs/heads/`), remote refs (i.e. under `refs/remotes/`),
- note refs (i.e. under `refs/notes/`), and the symbolic ref `HEAD`.
- If it is set to `always`, then a missing reflog is automatically
- created for any ref under `refs/`.
-+
-This information can be used to determine what commit
-was the tip of a branch "2 days ago".
-+
-This value is true by default in a repository that has
-a working directory associated with it, and false by
-default in a bare repository.
-
-core.repositoryFormatVersion::
- Internal variable identifying the repository format and layout
- version.
-
-core.sharedRepository::
- When 'group' (or 'true'), the repository is made shareable between
- several users in a group (making sure all the files and objects are
- group-writable). When 'all' (or 'world' or 'everybody'), the
- repository will be readable by all users, additionally to being
- group-shareable. When 'umask' (or 'false'), Git will use permissions
- reported by umask(2). When '0xxx', where '0xxx' is an octal number,
- files in the repository will have this mode value. '0xxx' will override
- user's umask value (whereas the other options will only override
- requested parts of the user's umask value). Examples: '0660' will make
- the repo read/write-able for the owner and group, but inaccessible to
- others (equivalent to 'group' unless umask is e.g. '0022'). '0640' is a
- repository that is group-readable but not group-writable.
- See linkgit:git-init[1]. False by default.
-
-core.warnAmbiguousRefs::
- If true, Git will warn you if the ref name you passed it is ambiguous
- and might match multiple refs in the repository. True by default.
-
-core.compression::
- An integer -1..9, indicating a default compression level.
- -1 is the zlib default. 0 means no compression,
- and 1..9 are various speed/size tradeoffs, 9 being slowest.
- If set, this provides a default to other compression variables,
- such as `core.looseCompression` and `pack.compression`.
-
-core.looseCompression::
- An integer -1..9, indicating the compression level for objects that
- are not in a pack file. -1 is the zlib default. 0 means no
- compression, and 1..9 are various speed/size tradeoffs, 9 being
- slowest. If not set, defaults to core.compression. If that is
- not set, defaults to 1 (best speed).
-
-core.packedGitWindowSize::
- Number of bytes of a pack file to map into memory in a
- single mapping operation. Larger window sizes may allow
- your system to process a smaller number of large pack files
- more quickly. Smaller window sizes will negatively affect
- performance due to increased calls to the operating system's
- memory manager, but may improve performance when accessing
- a large number of large pack files.
-+
-Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32
-MiB on 32 bit platforms and 1 GiB on 64 bit platforms. This should
-be reasonable for all users/operating systems. You probably do
-not need to adjust this value.
-+
-Common unit suffixes of 'k', 'm', or 'g' are supported.
+include::config/core.txt[]
-core.packedGitLimit::
- Maximum number of bytes to map simultaneously into memory
- from pack files. If Git needs to access more than this many
- bytes at once to complete an operation it will unmap existing
- regions to reclaim virtual address space within the process.
-+
-Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.
-This should be reasonable for all users/operating systems, except on
-the largest projects. You probably do not need to adjust this value.
-+
-Common unit suffixes of 'k', 'm', or 'g' are supported.
-
-core.deltaBaseCacheLimit::
- Maximum number of bytes to reserve for caching base objects
- that may be referenced by multiple deltified objects. By storing the
- entire decompressed base objects in a cache Git is able
- to avoid unpacking and decompressing frequently used base
- objects multiple times.
-+
-Default is 96 MiB on all platforms. This should be reasonable
-for all users/operating systems, except on the largest projects.
-You probably do not need to adjust this value.
-+
-Common unit suffixes of 'k', 'm', or 'g' are supported.
-
-core.bigFileThreshold::
- Files larger than this size are stored deflated, without
- attempting delta compression. Storing large files without
- delta compression avoids excessive memory usage, at the
- slight expense of increased disk usage. Additionally files
- larger than this size are always treated as binary.
-+
-Default is 512 MiB on all platforms. This should be reasonable
-for most projects as source code and other text files can still
-be delta compressed, but larger binary media files won't be.
-+
-Common unit suffixes of 'k', 'm', or 'g' are supported.
-
-core.excludesFile::
- Specifies the pathname to the file that contains patterns to
- describe paths that are not meant to be tracked, in addition
- to '.gitignore' (per-directory) and '.git/info/exclude'.
- Defaults to `$XDG_CONFIG_HOME/git/ignore`.
- If `$XDG_CONFIG_HOME` is either not set or empty, `$HOME/.config/git/ignore`
- is used instead. See linkgit:gitignore[5].
-
-core.askPass::
- Some commands (e.g. svn and http interfaces) that interactively
- ask for a password can be told to use an external program given
- via the value of this variable. Can be overridden by the `GIT_ASKPASS`
- environment variable. If not set, fall back to the value of the
- `SSH_ASKPASS` environment variable or, failing that, a simple password
- prompt. The external program shall be given a suitable prompt as
- command-line argument and write the password on its STDOUT.
-
-core.attributesFile::
- In addition to '.gitattributes' (per-directory) and
- '.git/info/attributes', Git looks into this file for attributes
- (see linkgit:gitattributes[5]). Path expansions are made the same
- way as for `core.excludesFile`. Its default value is
- `$XDG_CONFIG_HOME/git/attributes`. If `$XDG_CONFIG_HOME` is either not
- set or empty, `$HOME/.config/git/attributes` is used instead.
-
-core.hooksPath::
- By default Git will look for your hooks in the
- '$GIT_DIR/hooks' directory. Set this to different path,
- e.g. '/etc/git/hooks', and Git will try to find your hooks in
- that directory, e.g. '/etc/git/hooks/pre-receive' instead of
- in '$GIT_DIR/hooks/pre-receive'.
-+
-The path can be either absolute or relative. A relative path is
-taken as relative to the directory where the hooks are run (see
-the "DESCRIPTION" section of linkgit:githooks[5]).
-+
-This configuration variable is useful in cases where you'd like to
-centrally configure your Git hooks instead of configuring them on a
-per-repository basis, or as a more flexible and centralized
-alternative to having an `init.templateDir` where you've changed
-default hooks.
-
-core.editor::
- Commands such as `commit` and `tag` that lets you edit
- messages by launching an editor uses the value of this
- variable when it is set, and the environment variable
- `GIT_EDITOR` is not set. See linkgit:git-var[1].
-
-core.commentChar::
- Commands such as `commit` and `tag` that lets you edit
- messages consider a line that begins with this character
- commented, and removes them after the editor returns
- (default '#').
-+
-If set to "auto", `git-commit` would select a character that is not
-the beginning character of any line in existing commit messages.
-
-core.packedRefsTimeout::
- The length of time, in milliseconds, to retry when trying to
- lock the `packed-refs` file. Value 0 means not to retry at
- all; -1 means to try indefinitely. Default is 1000 (i.e.,
- retry for 1 second).
-
-sequence.editor::
- Text editor used by `git rebase -i` for editing the rebase instruction file.
- The value is meant to be interpreted by the shell when it is used.
- It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
- When not configured the default commit message editor is used instead.
-
-core.pager::
- Text viewer for use by Git commands (e.g., 'less'). The value
- is meant to be interpreted by the shell. The order of preference
- is the `$GIT_PAGER` environment variable, then `core.pager`
- configuration, then `$PAGER`, and then the default chosen at
- compile time (usually 'less').
-+
-When the `LESS` environment variable is unset, Git sets it to `FRX`
-(if `LESS` environment variable is set, Git does not change it at
-all). If you want to selectively override Git's default setting
-for `LESS`, you can set `core.pager` to e.g. `less -S`. This will
-be passed to the shell by Git, which will translate the final
-command to `LESS=FRX less -S`. The environment does not set the
-`S` option but the command line does, instructing less to truncate
-long lines. Similarly, setting `core.pager` to `less -+F` will
-deactivate the `F` option specified by the environment from the
-command-line, deactivating the "quit if one screen" behavior of
-`less`. One can specifically activate some flags for particular
-commands: for example, setting `pager.blame` to `less -S` enables
-line truncation only for `git blame`.
-+
-Likewise, when the `LV` environment variable is unset, Git sets it
-to `-c`. You can override this setting by exporting `LV` with
-another value or setting `core.pager` to `lv +c`.
-
-core.whitespace::
- A comma separated list of common whitespace problems to
- notice. 'git diff' will use `color.diff.whitespace` to
- highlight them, and 'git apply --whitespace=error' will
- consider them as errors. You can prefix `-` to disable
- any of them (e.g. `-trailing-space`):
-+
-* `blank-at-eol` treats trailing whitespaces at the end of the line
- as an error (enabled by default).
-* `space-before-tab` treats a space character that appears immediately
- before a tab character in the initial indent part of the line as an
- error (enabled by default).
-* `indent-with-non-tab` treats a line that is indented with space
- characters instead of the equivalent tabs as an error (not enabled by
- default).
-* `tab-in-indent` treats a tab character in the initial indent part of
- the line as an error (not enabled by default).
-* `blank-at-eof` treats blank lines added at the end of file as an error
- (enabled by default).
-* `trailing-space` is a short-hand to cover both `blank-at-eol` and
- `blank-at-eof`.
-* `cr-at-eol` treats a carriage-return at the end of line as
- part of the line terminator, i.e. with it, `trailing-space`
- does not trigger if the character before such a carriage-return
- is not a whitespace (not enabled by default).
-* `tabwidth=<n>` tells how many character positions a tab occupies; this
- is relevant for `indent-with-non-tab` and when Git fixes `tab-in-indent`
- errors. The default tab width is 8. Allowed values are 1 to 63.
-
-core.fsyncObjectFiles::
- This boolean will enable 'fsync()' when writing object files.
-+
-This is a total waste of time and effort on a filesystem that orders
-data writes properly, but can be useful for filesystems that do not use
-journalling (traditional UNIX filesystems) or that only journal metadata
-and not file contents (OS X's HFS+, or Linux ext3 with "data=writeback").
+include::config/add.txt[]
-core.preloadIndex::
- Enable parallel index preload for operations like 'git diff'
-+
-This can speed up operations like 'git diff' and 'git status' especially
-on filesystems like NFS that have weak caching semantics and thus
-relatively high IO latencies. When enabled, Git will do the
-index comparison to the filesystem data in parallel, allowing
-overlapping IO's. Defaults to true.
-
-core.createObject::
- You can set this to 'link', in which case a hardlink followed by
- a delete of the source are used to make sure that object creation
- will not overwrite existing objects.
-+
-On some file system/operating system combinations, this is unreliable.
-Set this config setting to 'rename' there; However, This will remove the
-check that makes sure that existing object files will not get overwritten.
-
-core.notesRef::
- When showing commit messages, also show notes which are stored in
- the given ref. The ref must be fully qualified. If the given
- ref does not exist, it is not an error but means that no
- notes should be printed.
-+
-This setting defaults to "refs/notes/commits", and it can be overridden by
-the `GIT_NOTES_REF` environment variable. See linkgit:git-notes[1].
-
-core.sparseCheckout::
- Enable "sparse checkout" feature. See section "Sparse checkout" in
- linkgit:git-read-tree[1] for more information.
-
-core.abbrev::
- Set the length object names are abbreviated to. If
- unspecified or set to "auto", an appropriate value is
- computed based on the approximate number of packed objects
- in your repository, which hopefully is enough for
- abbreviated object names to stay unique for some time.
-
-add.ignoreErrors::
-add.ignore-errors (deprecated)::
- Tells 'git add' to continue adding files when some files cannot be
- added due to indexing errors. Equivalent to the `--ignore-errors`
- option of linkgit:git-add[1]. `add.ignore-errors` is deprecated,
- as it does not follow the usual naming convention for configuration
- variables.
-
-alias.*::
- Command aliases for the linkgit:git[1] command wrapper - e.g.
- after defining "alias.last = cat-file commit HEAD", the invocation
- "git last" is equivalent to "git cat-file commit HEAD". To avoid
- confusion and troubles with script usage, aliases that
- hide existing Git commands are ignored. Arguments are split by
- spaces, the usual shell quoting and escaping is supported.
- A quote pair or a backslash can be used to quote them.
-+
-If the alias expansion is prefixed with an exclamation point,
-it will be treated as a shell command. For example, defining
-"alias.new = !gitk --all --not ORIG_HEAD", the invocation
-"git new" is equivalent to running the shell command
-"gitk --all --not ORIG_HEAD". Note that shell commands will be
-executed from the top-level directory of a repository, which may
-not necessarily be the current directory.
-`GIT_PREFIX` is set as returned by running 'git rev-parse --show-prefix'
-from the original current directory. See linkgit:git-rev-parse[1].
-
-am.keepcr::
- If true, git-am will call git-mailsplit for patches in mbox format
- with parameter `--keep-cr`. In this case git-mailsplit will
- not remove `\r` from lines ending with `\r\n`. Can be overridden
- by giving `--no-keep-cr` from the command line.
- See linkgit:git-am[1], linkgit:git-mailsplit[1].
-
-am.threeWay::
- By default, `git am` will fail if the patch does not apply cleanly. When
- set to true, this setting tells `git am` to fall back on 3-way merge if
- the patch records the identity of blobs it is supposed to apply to and
- we have those blobs available locally (equivalent to giving the `--3way`
- option from the command line). Defaults to `false`.
- See linkgit:git-am[1].
-
-apply.ignoreWhitespace::
- When set to 'change', tells 'git apply' to ignore changes in
- whitespace, in the same way as the `--ignore-space-change`
- option.
- When set to one of: no, none, never, false tells 'git apply' to
- respect all whitespace differences.
- See linkgit:git-apply[1].
-
-apply.whitespace::
- Tells 'git apply' how to handle whitespaces, in the same way
- as the `--whitespace` option. See linkgit:git-apply[1].
-
-branch.autoSetupMerge::
- Tells 'git branch' and 'git checkout' to set up new branches
- so that linkgit:git-pull[1] will appropriately merge from the
- starting point branch. Note that even if this option is not set,
- this behavior can be chosen per-branch using the `--track`
- and `--no-track` options. The valid settings are: `false` -- no
- automatic setup is done; `true` -- automatic setup is done when the
- starting point is a remote-tracking branch; `always` --
- automatic setup is done when the starting point is either a
- local branch or remote-tracking
- branch. This option defaults to true.
-
-branch.autoSetupRebase::
- When a new branch is created with 'git branch' or 'git checkout'
- that tracks another branch, this variable tells Git to set
- up pull to rebase instead of merge (see "branch.<name>.rebase").
- When `never`, rebase is never automatically set to true.
- When `local`, rebase is set to true for tracked branches of
- other local branches.
- When `remote`, rebase is set to true for tracked branches of
- remote-tracking branches.
- When `always`, rebase will be set to true for all tracking
- branches.
- See "branch.autoSetupMerge" for details on how to set up a
- branch to track another branch.
- This option defaults to never.
-
-branch.<name>.remote::
- When on branch <name>, it tells 'git fetch' and 'git push'
- which remote to fetch from/push to. The remote to push to
- may be overridden with `remote.pushDefault` (for all branches).
- The remote to push to, for the current branch, may be further
- overridden by `branch.<name>.pushRemote`. If no remote is
- configured, or if you are not on any branch, it defaults to
- `origin` for fetching and `remote.pushDefault` for pushing.
- Additionally, `.` (a period) is the current local repository
- (a dot-repository), see `branch.<name>.merge`'s final note below.
-
-branch.<name>.pushRemote::
- When on branch <name>, it overrides `branch.<name>.remote` for
- pushing. It also overrides `remote.pushDefault` for pushing
- from branch <name>. When you pull from one place (e.g. your
- upstream) and push to another place (e.g. your own publishing
- repository), you would want to set `remote.pushDefault` to
- specify the remote to push to for all branches, and use this
- option to override it for a specific branch.
-
-branch.<name>.merge::
- Defines, together with branch.<name>.remote, the upstream branch
- for the given branch. It tells 'git fetch'/'git pull'/'git rebase' which
- branch to merge and can also affect 'git push' (see push.default).
- When in branch <name>, it tells 'git fetch' the default
- refspec to be marked for merging in FETCH_HEAD. The value is
- handled like the remote part of a refspec, and must match a
- ref which is fetched from the remote given by
- "branch.<name>.remote".
- The merge information is used by 'git pull' (which at first calls
- 'git fetch') to lookup the default branch for merging. Without
- this option, 'git pull' defaults to merge the first refspec fetched.
- Specify multiple values to get an octopus merge.
- If you wish to setup 'git pull' so that it merges into <name> from
- another branch in the local repository, you can point
- branch.<name>.merge to the desired branch, and use the relative path
- setting `.` (a period) for branch.<name>.remote.
-
-branch.<name>.mergeOptions::
- Sets default options for merging into branch <name>. The syntax and
- supported options are the same as those of linkgit:git-merge[1], but
- option values containing whitespace characters are currently not
- supported.
-
-branch.<name>.rebase::
- When true, rebase the branch <name> on top of the fetched branch,
- instead of merging the default branch from the default remote when
- "git pull" is run. See "pull.rebase" for doing this in a non
- branch-specific manner.
-+
-When preserve, also pass `--preserve-merges` along to 'git rebase'
-so that locally committed merge commits will not be flattened
-by running 'git pull'.
-+
-When the value is `interactive`, the rebase is run in interactive mode.
-+
-*NOTE*: this is a possibly dangerous operation; do *not* use
-it unless you understand the implications (see linkgit:git-rebase[1]
-for details).
-
-branch.<name>.description::
- Branch description, can be edited with
- `git branch --edit-description`. Branch description is
- automatically added in the format-patch cover letter or
- request-pull summary.
-
-browser.<tool>.cmd::
- Specify the command to invoke the specified browser. The
- specified command is evaluated in shell with the URLs passed
- as arguments. (See linkgit:git-web{litdd}browse[1].)
-
-browser.<tool>.path::
- Override the path for the given tool that may be used to
- browse HTML help (see `-w` option in linkgit:git-help[1]) or a
- working repository in gitweb (see linkgit:git-instaweb[1]).
-
-clean.requireForce::
- A boolean to make git-clean do nothing unless given -f,
- -i or -n. Defaults to true.
-
-color.branch::
- A boolean to enable/disable color in the output of
- linkgit:git-branch[1]. May be set to `always`,
- `false` (or `never`) or `auto` (or `true`), in which case colors are used
- only when the output is to a terminal. If unset, then the
- value of `color.ui` is used (`auto` by default).
-
-color.branch.<slot>::
- Use customized color for branch coloration. `<slot>` is one of
- `current` (the current branch), `local` (a local branch),
- `remote` (a remote-tracking branch in refs/remotes/),
- `upstream` (upstream tracking branch), `plain` (other
- refs).
-
-color.diff::
- Whether to use ANSI escape sequences to add color to patches.
- If this is set to `always`, linkgit:git-diff[1],
- linkgit:git-log[1], and linkgit:git-show[1] will use color
- for all patches. If it is set to `true` or `auto`, those
- commands will only use color when output is to the terminal.
- If unset, then the value of `color.ui` is used (`auto` by
- default).
-+
-This does not affect linkgit:git-format-patch[1] or the
-'git-diff-{asterisk}' plumbing commands. Can be overridden on the
-command line with the `--color[=<when>]` option.
-
-color.diff.<slot>::
- Use customized color for diff colorization. `<slot>` specifies
- which part of the patch to use the specified color, and is one
- of `context` (context text - `plain` is a historical synonym),
- `meta` (metainformation), `frag`
- (hunk header), 'func' (function in hunk header), `old` (removed lines),
- `new` (added lines), `commit` (commit headers), or `whitespace`
- (highlighting whitespace errors).
-
-color.decorate.<slot>::
- Use customized color for 'git log --decorate' output. `<slot>` is one
- of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local
- branches, remote-tracking branches, tags, stash and HEAD, respectively.
-
-color.grep::
- When set to `always`, always highlight matches. When `false` (or
- `never`), never. When set to `true` or `auto`, use color only
- when the output is written to the terminal. If unset, then the
- value of `color.ui` is used (`auto` by default).
-
-color.grep.<slot>::
- Use customized color for grep colorization. `<slot>` specifies which
- part of the line to use the specified color, and is one of
-+
---
-`context`;;
- non-matching text in context lines (when using `-A`, `-B`, or `-C`)
-`filename`;;
- filename prefix (when not using `-h`)
-`function`;;
- function name lines (when using `-p`)
-`linenumber`;;
- line number prefix (when using `-n`)
-`match`;;
- matching text (same as setting `matchContext` and `matchSelected`)
-`matchContext`;;
- matching text in context lines
-`matchSelected`;;
- matching text in selected lines
-`selected`;;
- non-matching text in selected lines
-`separator`;;
- separators between fields on a line (`:`, `-`, and `=`)
- and between hunks (`--`)
---
-
-color.interactive::
- When set to `always`, always use colors for interactive prompts
- and displays (such as those used by "git-add --interactive" and
- "git-clean --interactive"). When false (or `never`), never.
- When set to `true` or `auto`, use colors only when the output is
- to the terminal. If unset, then the value of `color.ui` is
- used (`auto` by default).
-
-color.interactive.<slot>::
- Use customized color for 'git add --interactive' and 'git clean
- --interactive' output. `<slot>` may be `prompt`, `header`, `help`
- or `error`, for four distinct types of normal output from
- interactive commands.
-
-color.pager::
- A boolean to enable/disable colored output when the pager is in
- use (default is true).
-
-color.showBranch::
- A boolean to enable/disable color in the output of
- linkgit:git-show-branch[1]. May be set to `always`,
- `false` (or `never`) or `auto` (or `true`), in which case colors are used
- only when the output is to a terminal. If unset, then the
- value of `color.ui` is used (`auto` by default).
-
-color.status::
- A boolean to enable/disable color in the output of
- linkgit:git-status[1]. May be set to `always`,
- `false` (or `never`) or `auto` (or `true`), in which case colors are used
- only when the output is to a terminal. If unset, then the
- value of `color.ui` is used (`auto` by default).
-
-color.status.<slot>::
- Use customized color for status colorization. `<slot>` is
- one of `header` (the header text of the status message),
- `added` or `updated` (files which are added but not committed),
- `changed` (files which are changed but not added in the index),
- `untracked` (files which are not tracked by Git),
- `branch` (the current branch),
- `nobranch` (the color the 'no branch' warning is shown in, defaulting
- to red), or
- `unmerged` (files which have unmerged changes).
-
-color.ui::
- This variable determines the default value for variables such
- as `color.diff` and `color.grep` that control the use of color
- per command family. Its scope will expand as more commands learn
- configuration to set a default for the `--color` option. Set it
- to `false` or `never` if you prefer Git commands not to use
- color unless enabled explicitly with some other configuration
- or the `--color` option. Set it to `always` if you want all
- output not intended for machine consumption to use color, to
- `true` or `auto` (this is the default since Git 1.8.4) if you
- want such output to use color when written to the terminal.
-
-column.ui::
- Specify whether supported commands should output in columns.
- This variable consists of a list of tokens separated by spaces
- or commas:
-+
-These options control when the feature should be enabled
-(defaults to 'never'):
-+
---
-`always`;;
- always show in columns
-`never`;;
- never show in columns
-`auto`;;
- show in columns if the output is to the terminal
---
-+
-These options control layout (defaults to 'column'). Setting any
-of these implies 'always' if none of 'always', 'never', or 'auto' are
-specified.
-+
---
-`column`;;
- fill columns before rows
-`row`;;
- fill rows before columns
-`plain`;;
- show in one column
---
-+
-Finally, these options can be combined with a layout option (defaults
-to 'nodense'):
-+
---
-`dense`;;
- make unequal size columns to utilize more space
-`nodense`;;
- make equal size columns
---
-
-column.branch::
- Specify whether to output branch listing in `git branch` in columns.
- See `column.ui` for details.
-
-column.clean::
- Specify the layout when list items in `git clean -i`, which always
- shows files and directories in columns. See `column.ui` for details.
-
-column.status::
- Specify whether to output untracked files in `git status` in columns.
- See `column.ui` for details.
-
-column.tag::
- Specify whether to output tag listing in `git tag` in columns.
- See `column.ui` for details.
-
-commit.cleanup::
- This setting overrides the default of the `--cleanup` option in
- `git commit`. See linkgit:git-commit[1] for details. Changing the
- default can be useful when you always want to keep lines that begin
- with comment character `#` in your log message, in which case you
- would do `git config commit.cleanup whitespace` (note that you will
- have to remove the help lines that begin with `#` in the commit log
- template yourself, if you do this).
-
-commit.gpgSign::
-
- A boolean to specify whether all commits should be GPG signed.
- Use of this option when doing operations such as rebase can
- result in a large number of commits being signed. It may be
- convenient to use an agent to avoid typing your GPG passphrase
- several times.
-
-commit.status::
- A boolean to enable/disable inclusion of status information in the
- commit message template when using an editor to prepare the commit
- message. Defaults to true.
-
-commit.template::
- Specify the pathname of a file to use as the template for
- new commit messages.
-
-commit.verbose::
- A boolean or int to specify the level of verbose with `git commit`.
- See linkgit:git-commit[1].
-
-credential.helper::
- Specify an external helper to be called when a username or
- password credential is needed; the helper may consult external
- storage to avoid prompting the user for the credentials. Note
- that multiple helpers may be defined. See linkgit:gitcredentials[7]
- for details.
-
-credential.useHttpPath::
- When acquiring credentials, consider the "path" component of an http
- or https URL to be important. Defaults to false. See
- linkgit:gitcredentials[7] for more information.
-
-credential.username::
- If no username is set for a network authentication, use this username
- by default. See credential.<context>.* below, and
- linkgit:gitcredentials[7].
-
-credential.<url>.*::
- Any of the credential.* options above can be applied selectively to
- some credentials. For example "credential.https://example.com.username"
- would set the default username only for https connections to
- example.com. See linkgit:gitcredentials[7] for details on how URLs are
- matched.
-
-credentialCache.ignoreSIGHUP::
- Tell git-credential-cache--daemon to ignore SIGHUP, instead of quitting.
-
-include::diff-config.txt[]
-
-difftool.<tool>.path::
- Override the path for the given tool. This is useful in case
- your tool is not in the PATH.
-
-difftool.<tool>.cmd::
- Specify the command to invoke the specified diff tool.
- The specified command is evaluated in shell with the following
- variables available: 'LOCAL' is set to the name of the temporary
- file containing the contents of the diff pre-image and 'REMOTE'
- is set to the name of the temporary file containing the contents
- of the diff post-image.
-
-difftool.prompt::
- Prompt before each invocation of the diff tool.
-
-fastimport.unpackLimit::
- If the number of objects imported by linkgit:git-fast-import[1]
- is below this limit, then the objects will be unpacked into
- loose object files. However if the number of imported objects
- equals or exceeds this limit then the pack will be stored as a
- pack. Storing the pack from a fast-import can make the import
- operation complete faster, especially on slow filesystems. If
- not set, the value of `transfer.unpackLimit` is used instead.
-
-fetch.recurseSubmodules::
- This option can be either set to a boolean value or to 'on-demand'.
- Setting it to a boolean changes the behavior of fetch and pull to
- unconditionally recurse into submodules when set to true or to not
- recurse at all when set to false. When set to 'on-demand' (the default
- value), fetch and pull will only recurse into a populated submodule
- when its superproject retrieves a commit that updates the submodule's
- reference.
-
-fetch.fsckObjects::
- If it is set to true, git-fetch-pack will check all fetched
- objects. It will abort in the case of a malformed object or a
- broken link. The result of an abort are only dangling objects.
- Defaults to false. If not set, the value of `transfer.fsckObjects`
- is used instead.
-
-fetch.unpackLimit::
- If the number of objects fetched over the Git native
- transfer is below this
- limit, then the objects will be unpacked into loose object
- files. However if the number of received objects equals or
- exceeds this limit then the received pack will be stored as
- a pack, after adding any missing delta bases. Storing the
- pack from a push can make the push operation complete faster,
- especially on slow filesystems. If not set, the value of
- `transfer.unpackLimit` is used instead.
-
-fetch.prune::
- If true, fetch will automatically behave as if the `--prune`
- option was given on the command line. See also `remote.<name>.prune`.
-
-fetch.output::
- Control how ref update status is printed. Valid values are
- `full` and `compact`. Default value is `full`. See section
- OUTPUT in linkgit:git-fetch[1] for detail.
-
-format.attach::
- Enable multipart/mixed attachments as the default for
- 'format-patch'. The value can also be a double quoted string
- which will enable attachments as the default and set the
- value as the boundary. See the --attach option in
- linkgit:git-format-patch[1].
-
-format.from::
- Provides the default value for the `--from` option to format-patch.
- Accepts a boolean value, or a name and email address. If false,
- format-patch defaults to `--no-from`, using commit authors directly in
- the "From:" field of patch mails. If true, format-patch defaults to
- `--from`, using your committer identity in the "From:" field of patch
- mails and including a "From:" field in the body of the patch mail if
- different. If set to a non-boolean value, format-patch uses that
- value instead of your committer identity. Defaults to false.
-
-format.numbered::
- A boolean which can enable or disable sequence numbers in patch
- subjects. It defaults to "auto" which enables it only if there
- is more than one patch. It can be enabled or disabled for all
- messages by setting it to "true" or "false". See --numbered
- option in linkgit:git-format-patch[1].
-
-format.headers::
- Additional email headers to include in a patch to be submitted
- by mail. See linkgit:git-format-patch[1].
-
-format.to::
-format.cc::
- Additional recipients to include in a patch to be submitted
- by mail. See the --to and --cc options in
- linkgit:git-format-patch[1].
-
-format.subjectPrefix::
- The default for format-patch is to output files with the '[PATCH]'
- subject prefix. Use this variable to change that prefix.
-
-format.signature::
- The default for format-patch is to output a signature containing
- the Git version number. Use this variable to change that default.
- Set this variable to the empty string ("") to suppress
- signature generation.
-
-format.signatureFile::
- Works just like format.signature except the contents of the
- file specified by this variable will be used as the signature.
-
-format.suffix::
- The default for format-patch is to output files with the suffix
- `.patch`. Use this variable to change that suffix (make sure to
- include the dot if you want it).
-
-format.pretty::
- The default pretty format for log/show/whatchanged command,
- See linkgit:git-log[1], linkgit:git-show[1],
- linkgit:git-whatchanged[1].
-
-format.thread::
- The default threading style for 'git format-patch'. Can be
- a boolean value, or `shallow` or `deep`. `shallow` threading
- makes every mail a reply to the head of the series,
- where the head is chosen from the cover letter, the
- `--in-reply-to`, and the first patch mail, in this order.
- `deep` threading makes every mail a reply to the previous one.
- A true boolean value is the same as `shallow`, and a false
- value disables threading.
-
-format.signOff::
- A boolean value which lets you enable the `-s/--signoff` option of
- format-patch by default. *Note:* Adding the Signed-off-by: line to a
- patch should be a conscious act and means that you certify you have
- the rights to submit this work under the same open source license.
- Please see the 'SubmittingPatches' document for further discussion.
-
-format.coverLetter::
- A boolean that controls whether to generate a cover-letter when
- format-patch is invoked, but in addition can be set to "auto", to
- generate a cover-letter only when there's more than one patch.
-
-format.outputDirectory::
- Set a custom directory to store the resulting files instead of the
- current working directory.
-
-format.useAutoBase::
- A boolean value which lets you enable the `--base=auto` option of
- format-patch by default.
-
-filter.<driver>.clean::
- The command which is used to convert the content of a worktree
- file to a blob upon checkin. See linkgit:gitattributes[5] for
- details.
-
-filter.<driver>.smudge::
- The command which is used to convert the content of a blob
- object to a worktree file upon checkout. See
- linkgit:gitattributes[5] for details.
-
-fsck.<msg-id>::
- Allows overriding the message type (error, warn or ignore) of a
- specific message ID such as `missingEmail`.
-+
-For convenience, fsck prefixes the error/warning with the message ID,
-e.g. "missingEmail: invalid author/committer line - missing email" means
-that setting `fsck.missingEmail = ignore` will hide that issue.
-+
-This feature is intended to support working with legacy repositories
-which cannot be repaired without disruptive changes.
-
-fsck.skipList::
- The path to a sorted list of object names (i.e. one SHA-1 per
- line) that are known to be broken in a non-fatal way and should
- be ignored. This feature is useful when an established project
- should be accepted despite early commits containing errors that
- can be safely ignored such as invalid committer email addresses.
- Note: corrupt objects cannot be skipped with this setting.
-
-gc.aggressiveDepth::
- The depth parameter used in the delta compression
- algorithm used by 'git gc --aggressive'. This defaults
- to 50.
-
-gc.aggressiveWindow::
- The window size parameter used in the delta compression
- algorithm used by 'git gc --aggressive'. This defaults
- to 250.
-
-gc.auto::
- When there are approximately more than this many loose
- objects in the repository, `git gc --auto` will pack them.
- Some Porcelain commands use this command to perform a
- light-weight garbage collection from time to time. The
- default value is 6700. Setting this to 0 disables it.
-
-gc.autoPackLimit::
- When there are more than this many packs that are not
- marked with `*.keep` file in the repository, `git gc
- --auto` consolidates them into one larger pack. The
- default value is 50. Setting this to 0 disables it.
-
-gc.autoDetach::
- Make `git gc --auto` return immediately and run in background
- if the system supports it. Default is true.
-
-gc.logExpiry::
- If the file gc.log exists, then `git gc --auto` won't run
- unless that file is more than 'gc.logExpiry' old. Default is
- "1.day". See `gc.pruneExpire` for more ways to specify its
- value.
-
-gc.packRefs::
- Running `git pack-refs` in a repository renders it
- unclonable by Git versions prior to 1.5.1.2 over dumb
- transports such as HTTP. This variable determines whether
- 'git gc' runs `git pack-refs`. This can be set to `notbare`
- to enable it within all non-bare repos or it can be set to a
- boolean value. The default is `true`.
-
-gc.pruneExpire::
- When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'.
- Override the grace period with this config variable. The value
- "now" may be used to disable this grace period and always prune
- unreachable objects immediately, or "never" may be used to
- suppress pruning. This feature helps prevent corruption when
- 'git gc' runs concurrently with another process writing to the
- repository; see the "NOTES" section of linkgit:git-gc[1].
-
-gc.worktreePruneExpire::
- When 'git gc' is run, it calls
- 'git worktree prune --expire 3.months.ago'.
- This config variable can be used to set a different grace
- period. The value "now" may be used to disable the grace
- period and prune `$GIT_DIR/worktrees` immediately, or "never"
- may be used to suppress pruning.
-
-gc.reflogExpire::
-gc.<pattern>.reflogExpire::
- 'git reflog expire' removes reflog entries older than
- this time; defaults to 90 days. The value "now" expires all
- entries immediately, and "never" suppresses expiration
- altogether. With "<pattern>" (e.g.
- "refs/stash") in the middle the setting applies only to
- the refs that match the <pattern>.
-
-gc.reflogExpireUnreachable::
-gc.<pattern>.reflogExpireUnreachable::
- 'git reflog expire' removes reflog entries older than
- this time and are not reachable from the current tip;
- defaults to 30 days. The value "now" expires all entries
- immediately, and "never" suppresses expiration altogether.
- With "<pattern>" (e.g. "refs/stash")
- in the middle, the setting applies only to the refs that
- match the <pattern>.
-
-gc.rerereResolved::
- Records of conflicted merge you resolved earlier are
- kept for this many days when 'git rerere gc' is run.
- The default is 60 days. See linkgit:git-rerere[1].
-
-gc.rerereUnresolved::
- Records of conflicted merge you have not resolved are
- kept for this many days when 'git rerere gc' is run.
- The default is 15 days. See linkgit:git-rerere[1].
-
-gitcvs.commitMsgAnnotation::
- Append this string to each commit message. Set to empty string
- to disable this feature. Defaults to "via git-CVS emulator".
-
-gitcvs.enabled::
- Whether the CVS server interface is enabled for this repository.
- See linkgit:git-cvsserver[1].
-
-gitcvs.logFile::
- Path to a log file where the CVS server interface well... logs
- various stuff. See linkgit:git-cvsserver[1].
-
-gitcvs.usecrlfattr::
- If true, the server will look up the end-of-line conversion
- attributes for files to determine the `-k` modes to use. If
- the attributes force Git to treat a file as text,
- the `-k` mode will be left blank so CVS clients will
- treat it as text. If they suppress text conversion, the file
- will be set with '-kb' mode, which suppresses any newline munging
- the client might otherwise do. If the attributes do not allow
- the file type to be determined, then `gitcvs.allBinary` is
- used. See linkgit:gitattributes[5].
-
-gitcvs.allBinary::
- This is used if `gitcvs.usecrlfattr` does not resolve
- the correct '-kb' mode to use. If true, all
- unresolved files are sent to the client in
- mode '-kb'. This causes the client to treat them
- as binary files, which suppresses any newline munging it
- otherwise might do. Alternatively, if it is set to "guess",
- then the contents of the file are examined to decide if
- it is binary, similar to `core.autocrlf`.
-
-gitcvs.dbName::
- Database used by git-cvsserver to cache revision information
- derived from the Git repository. The exact meaning depends on the
- used database driver, for SQLite (which is the default driver) this
- is a filename. Supports variable substitution (see
- linkgit:git-cvsserver[1] for details). May not contain semicolons (`;`).
- Default: '%Ggitcvs.%m.sqlite'
-
-gitcvs.dbDriver::
- Used Perl DBI driver. You can specify any available driver
- for this here, but it might not work. git-cvsserver is tested
- with 'DBD::SQLite', reported to work with 'DBD::Pg', and
- reported *not* to work with 'DBD::mysql'. Experimental feature.
- May not contain double colons (`:`). Default: 'SQLite'.
- See linkgit:git-cvsserver[1].
-
-gitcvs.dbUser, gitcvs.dbPass::
- Database user and password. Only useful if setting `gitcvs.dbDriver`,
- since SQLite has no concept of database users and/or passwords.
- 'gitcvs.dbUser' supports variable substitution (see
- linkgit:git-cvsserver[1] for details).
-
-gitcvs.dbTableNamePrefix::
- Database table name prefix. Prepended to the names of any
- database tables used, allowing a single database to be used
- for several repositories. Supports variable substitution (see
- linkgit:git-cvsserver[1] for details). Any non-alphabetic
- characters will be replaced with underscores.
-
-All gitcvs variables except for `gitcvs.usecrlfattr` and
-`gitcvs.allBinary` can also be specified as
-'gitcvs.<access_method>.<varname>' (where 'access_method'
-is one of "ext" and "pserver") to make them apply only for the given
-access method.
-
-gitweb.category::
-gitweb.description::
-gitweb.owner::
-gitweb.url::
- See linkgit:gitweb[1] for description.
-
-gitweb.avatar::
-gitweb.blame::
-gitweb.grep::
-gitweb.highlight::
-gitweb.patches::
-gitweb.pickaxe::
-gitweb.remote_heads::
-gitweb.showSizes::
-gitweb.snapshot::
- See linkgit:gitweb.conf[5] for description.
-
-grep.lineNumber::
- If set to true, enable `-n` option by default.
-
-grep.patternType::
- Set the default matching behavior. Using a value of 'basic', 'extended',
- 'fixed', or 'perl' will enable the `--basic-regexp`, `--extended-regexp`,
- `--fixed-strings`, or `--perl-regexp` option accordingly, while the
- value 'default' will return to the default matching behavior.
-
-grep.extendedRegexp::
- If set to true, enable `--extended-regexp` option by default. This
- option is ignored when the `grep.patternType` option is set to a value
- other than 'default'.
-
-grep.threads::
- Number of grep worker threads to use.
- See `grep.threads` in linkgit:git-grep[1] for more information.
-
-grep.fallbackToNoIndex::
- If set to true, fall back to git grep --no-index if git grep
- is executed outside of a git repository. Defaults to false.
-
-gpg.program::
- Use this custom program instead of "`gpg`" found on `$PATH` when
- making or verifying a PGP signature. The program must support the
- same command-line interface as GPG, namely, to verify a detached
- signature, "`gpg --verify $file - <$signature`" is run, and the
- program is expected to signal a good signature by exiting with
- code 0, and to generate an ASCII-armored detached signature, the
- standard input of "`gpg -bsau $key`" is fed with the contents to be
- signed, and the program is expected to send the result to its
- standard output.
-
-gui.commitMsgWidth::
- Defines how wide the commit message window is in the
- linkgit:git-gui[1]. "75" is the default.
-
-gui.diffContext::
- Specifies how many context lines should be used in calls to diff
- made by the linkgit:git-gui[1]. The default is "5".
-
-gui.displayUntracked::
- Determines if linkgit:git-gui[1] shows untracked files
- in the file list. The default is "true".
-
-gui.encoding::
- Specifies the default encoding to use for displaying of
- file contents in linkgit:git-gui[1] and linkgit:gitk[1].
- It can be overridden by setting the 'encoding' attribute
- for relevant files (see linkgit:gitattributes[5]).
- If this option is not set, the tools default to the
- locale encoding.
-
-gui.matchTrackingBranch::
- Determines if new branches created with linkgit:git-gui[1] should
- default to tracking remote branches with matching names or
- not. Default: "false".
-
-gui.newBranchTemplate::
- Is used as suggested name when creating new branches using the
- linkgit:git-gui[1].
-
-gui.pruneDuringFetch::
- "true" if linkgit:git-gui[1] should prune remote-tracking branches when
- performing a fetch. The default value is "false".
-
-gui.trustmtime::
- Determines if linkgit:git-gui[1] should trust the file modification
- timestamp or not. By default the timestamps are not trusted.
-
-gui.spellingDictionary::
- Specifies the dictionary used for spell checking commit messages in
- the linkgit:git-gui[1]. When set to "none" spell checking is turned
- off.
-
-gui.fastCopyBlame::
- If true, 'git gui blame' uses `-C` instead of `-C -C` for original
- location detection. It makes blame significantly faster on huge
- repositories at the expense of less thorough copy detection.
-
-gui.copyBlameThreshold::
- Specifies the threshold to use in 'git gui blame' original location
- detection, measured in alphanumeric characters. See the
- linkgit:git-blame[1] manual for more information on copy detection.
-
-gui.blamehistoryctx::
- Specifies the radius of history context in days to show in
- linkgit:gitk[1] for the selected commit, when the `Show History
- Context` menu item is invoked from 'git gui blame'. If this
- variable is set to zero, the whole history is shown.
-
-guitool.<name>.cmd::
- Specifies the shell command line to execute when the corresponding item
- of the linkgit:git-gui[1] `Tools` menu is invoked. This option is
- mandatory for every tool. The command is executed from the root of
- the working directory, and in the environment it receives the name of
- the tool as `GIT_GUITOOL`, the name of the currently selected file as
- 'FILENAME', and the name of the current branch as 'CUR_BRANCH' (if
- the head is detached, 'CUR_BRANCH' is empty).
-
-guitool.<name>.needsFile::
- Run the tool only if a diff is selected in the GUI. It guarantees
- that 'FILENAME' is not empty.
-
-guitool.<name>.noConsole::
- Run the command silently, without creating a window to display its
- output.
-
-guitool.<name>.noRescan::
- Don't rescan the working directory for changes after the tool
- finishes execution.
-
-guitool.<name>.confirm::
- Show a confirmation dialog before actually running the tool.
-
-guitool.<name>.argPrompt::
- Request a string argument from the user, and pass it to the tool
- through the `ARGS` environment variable. Since requesting an
- argument implies confirmation, the 'confirm' option has no effect
- if this is enabled. If the option is set to 'true', 'yes', or '1',
- the dialog uses a built-in generic prompt; otherwise the exact
- value of the variable is used.
-
-guitool.<name>.revPrompt::
- Request a single valid revision from the user, and set the
- `REVISION` environment variable. In other aspects this option
- is similar to 'argPrompt', and can be used together with it.
-
-guitool.<name>.revUnmerged::
- Show only unmerged branches in the 'revPrompt' subdialog.
- This is useful for tools similar to merge or rebase, but not
- for things like checkout or reset.
-
-guitool.<name>.title::
- Specifies the title to use for the prompt dialog. The default
- is the tool name.
-
-guitool.<name>.prompt::
- Specifies the general prompt string to display at the top of
- the dialog, before subsections for 'argPrompt' and 'revPrompt'.
- The default value includes the actual command.
-
-help.browser::
- Specify the browser that will be used to display help in the
- 'web' format. See linkgit:git-help[1].
-
-help.format::
- Override the default help format used by linkgit:git-help[1].
- Values 'man', 'info', 'web' and 'html' are supported. 'man' is
- the default. 'web' and 'html' are the same.
-
-help.autoCorrect::
- Automatically correct and execute mistyped commands after
- waiting for the given number of deciseconds (0.1 sec). If more
- than one command can be deduced from the entered text, nothing
- will be executed. If the value of this option is negative,
- the corrected command will be executed immediately. If the
- value is 0 - the command will be just shown but not executed.
- This is the default.
-
-help.htmlPath::
- Specify the path where the HTML documentation resides. File system paths
- and URLs are supported. HTML pages will be prefixed with this path when
- help is displayed in the 'web' format. This defaults to the documentation
- path of your Git installation.
-
-http.proxy::
- Override the HTTP proxy, normally configured using the 'http_proxy',
- 'https_proxy', and 'all_proxy' environment variables (see `curl(1)`). In
- addition to the syntax understood by curl, it is possible to specify a
- proxy string with a user name but no password, in which case git will
- attempt to acquire one in the same way it does for other credentials. See
- linkgit:gitcredentials[7] for more information. The syntax thus is
- '[protocol://][user[:password]@]proxyhost[:port]'. This can be overridden
- on a per-remote basis; see remote.<name>.proxy
-
-http.proxyAuthMethod::
- Set the method with which to authenticate against the HTTP proxy. This
- only takes effect if the configured proxy string contains a user name part
- (i.e. is of the form 'user@host' or 'user@host:port'). This can be
- overridden on a per-remote basis; see `remote.<name>.proxyAuthMethod`.
- Both can be overridden by the `GIT_HTTP_PROXY_AUTHMETHOD` environment
- variable. Possible values are:
-+
---
-* `anyauth` - Automatically pick a suitable authentication method. It is
- assumed that the proxy answers an unauthenticated request with a 407
- status code and one or more Proxy-authenticate headers with supported
- authentication methods. This is the default.
-* `basic` - HTTP Basic authentication
-* `digest` - HTTP Digest authentication; this prevents the password from being
- transmitted to the proxy in clear text
-* `negotiate` - GSS-Negotiate authentication (compare the --negotiate option
- of `curl(1)`)
-* `ntlm` - NTLM authentication (compare the --ntlm option of `curl(1)`)
---
-
-http.emptyAuth::
- Attempt authentication without seeking a username or password. This
- can be used to attempt GSS-Negotiate authentication without specifying
- a username in the URL, as libcurl normally requires a username for
- authentication.
-
-http.delegation::
- Control GSSAPI credential delegation. The delegation is disabled
- by default in libcurl since version 7.21.7. Set parameter to tell
- the server what it is allowed to delegate when it comes to user
- credentials. Used with GSS/kerberos. Possible values are:
-+
---
-* `none` - Don't allow any delegation.
-* `policy` - Delegates if and only if the OK-AS-DELEGATE flag is set in the
- Kerberos service ticket, which is a matter of realm policy.
-* `always` - Unconditionally allow the server to delegate.
---
-
-
-http.extraHeader::
- Pass an additional HTTP header when communicating with a server. If
- more than one such entry exists, all of them are added as extra
- headers. To allow overriding the settings inherited from the system
- config, an empty value will reset the extra headers to the empty list.
-
-http.cookieFile::
- The pathname of a file containing previously stored cookie lines,
- which should be used
- in the Git http session, if they match the server. The file format
- of the file to read cookies from should be plain HTTP headers or
- the Netscape/Mozilla cookie file format (see `curl(1)`).
- NOTE that the file specified with http.cookieFile is used only as
- input unless http.saveCookies is set.
-
-http.saveCookies::
- If set, store cookies received during requests to the file specified by
- http.cookieFile. Has no effect if http.cookieFile is unset.
-
-http.sslVersion::
- The SSL version to use when negotiating an SSL connection, if you
- want to force the default. The available and default version
- depend on whether libcurl was built against NSS or OpenSSL and the
- particular configuration of the crypto library in use. Internally
- this sets the 'CURLOPT_SSL_VERSION' option; see the libcurl
- documentation for more details on the format of this option and
- for the ssl version supported. Actually the possible values of
- this option are:
-
- - sslv2
- - sslv3
- - tlsv1
- - tlsv1.0
- - tlsv1.1
- - tlsv1.2
+include::config/alias.txt[]
-+
-Can be overridden by the `GIT_SSL_VERSION` environment variable.
-To force git to use libcurl's default ssl version and ignore any
-explicit http.sslversion option, set `GIT_SSL_VERSION` to the
-empty string.
-
-http.sslCipherList::
- A list of SSL ciphers to use when negotiating an SSL connection.
- The available ciphers depend on whether libcurl was built against
- NSS or OpenSSL and the particular configuration of the crypto
- library in use. Internally this sets the 'CURLOPT_SSL_CIPHER_LIST'
- option; see the libcurl documentation for more details on the format
- of this list.
-+
-Can be overridden by the `GIT_SSL_CIPHER_LIST` environment variable.
-To force git to use libcurl's default cipher list and ignore any
-explicit http.sslCipherList option, set `GIT_SSL_CIPHER_LIST` to the
-empty string.
-
-http.sslVerify::
- Whether to verify the SSL certificate when fetching or pushing
- over HTTPS. Can be overridden by the `GIT_SSL_NO_VERIFY` environment
- variable.
-
-http.sslCert::
- File containing the SSL certificate when fetching or pushing
- over HTTPS. Can be overridden by the `GIT_SSL_CERT` environment
- variable.
-
-http.sslKey::
- File containing the SSL private key when fetching or pushing
- over HTTPS. Can be overridden by the `GIT_SSL_KEY` environment
- variable.
-
-http.sslCertPasswordProtected::
- Enable Git's password prompt for the SSL certificate. Otherwise
- OpenSSL will prompt the user, possibly many times, if the
- certificate or private key is encrypted. Can be overridden by the
- `GIT_SSL_CERT_PASSWORD_PROTECTED` environment variable.
-
-http.sslCAInfo::
- File containing the certificates to verify the peer with when
- fetching or pushing over HTTPS. Can be overridden by the
- `GIT_SSL_CAINFO` environment variable.
-
-http.sslCAPath::
- Path containing files with the CA certificates to verify the peer
- with when fetching or pushing over HTTPS. Can be overridden
- by the `GIT_SSL_CAPATH` environment variable.
-
-http.pinnedpubkey::
- Public key of the https service. It may either be the filename of
- a PEM or DER encoded public key file or a string starting with
- 'sha256//' followed by the base64 encoded sha256 hash of the
- public key. See also libcurl 'CURLOPT_PINNEDPUBLICKEY'. git will
- exit with an error if this option is set but not supported by
- cURL.
-
-http.sslTry::
- Attempt to use AUTH SSL/TLS and encrypted data transfers
- when connecting via regular FTP protocol. This might be needed
- if the FTP server requires it for security reasons or you wish
- to connect securely whenever remote FTP server supports it.
- Default is false since it might trigger certificate verification
- errors on misconfigured servers.
-
-http.maxRequests::
- How many HTTP requests to launch in parallel. Can be overridden
- by the `GIT_HTTP_MAX_REQUESTS` environment variable. Default is 5.
-
-http.minSessions::
- The number of curl sessions (counted across slots) to be kept across
- requests. They will not be ended with curl_easy_cleanup() until
- http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this
- value will be capped at 1. Defaults to 1.
-
-http.postBuffer::
- Maximum size in bytes of the buffer used by smart HTTP
- transports when POSTing data to the remote system.
- For requests larger than this buffer size, HTTP/1.1 and
- Transfer-Encoding: chunked is used to avoid creating a
- massive pack file locally. Default is 1 MiB, which is
- sufficient for most requests.
-
-http.lowSpeedLimit, http.lowSpeedTime::
- If the HTTP transfer speed is less than 'http.lowSpeedLimit'
- for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
- Can be overridden by the `GIT_HTTP_LOW_SPEED_LIMIT` and
- `GIT_HTTP_LOW_SPEED_TIME` environment variables.
-
-http.noEPSV::
- A boolean which disables using of EPSV ftp command by curl.
- This can helpful with some "poor" ftp servers which don't
- support EPSV mode. Can be overridden by the `GIT_CURL_FTP_NO_EPSV`
- environment variable. Default is false (curl will use EPSV).
-
-http.userAgent::
- The HTTP USER_AGENT string presented to an HTTP server. The default
- value represents the version of the client Git such as git/1.7.1.
- This option allows you to override this value to a more common value
- such as Mozilla/4.0. This may be necessary, for instance, if
- connecting through a firewall that restricts HTTP connections to a set
- of common USER_AGENT strings (but not including those like git/1.7.1).
- Can be overridden by the `GIT_HTTP_USER_AGENT` environment variable.
-
-http.followRedirects::
- Whether git should follow HTTP redirects. If set to `true`, git
- will transparently follow any redirect issued by a server it
- encounters. If set to `false`, git will treat all redirects as
- errors. If set to `initial`, git will follow redirects only for
- the initial request to a remote, but not for subsequent
- follow-up HTTP requests. Since git uses the redirected URL as
- the base for the follow-up requests, this is generally
- sufficient. The default is `initial`.
-
-http.<url>.*::
- Any of the http.* options above can be applied selectively to some URLs.
- For a config key to match a URL, each element of the config key is
- compared to that of the URL, in the following order:
-+
---
-. Scheme (e.g., `https` in `https://example.com/`). This field
- must match exactly between the config key and the URL.
-
-. Host/domain name (e.g., `example.com` in `https://example.com/`).
- This field must match between the config key and the URL. It is
- possible to specify a `*` as part of the host name to match all subdomains
- at this level. `https://*.example.com/` for example would match
- `https://foo.example.com/`, but not `https://foo.bar.example.com/`.
-
-. Port number (e.g., `8080` in `http://example.com:8080/`).
- This field must match exactly between the config key and the URL.
- Omitted port numbers are automatically converted to the correct
- default for the scheme before matching.
-
-. Path (e.g., `repo.git` in `https://example.com/repo.git`). The
- path field of the config key must match the path field of the URL
- either exactly or as a prefix of slash-delimited path elements. This means
- a config key with path `foo/` matches URL path `foo/bar`. A prefix can only
- match on a slash (`/`) boundary. Longer matches take precedence (so a config
- key with path `foo/bar` is a better match to URL path `foo/bar` than a config
- key with just path `foo/`).
-
-. User name (e.g., `user` in `https://user@example.com/repo.git`). If
- the config key has a user name it must match the user name in the
- URL exactly. If the config key does not have a user name, that
- config key will match a URL with any user name (including none),
- but at a lower precedence than a config key with a user name.
---
-+
-The list above is ordered by decreasing precedence; a URL that matches
-a config key's path is preferred to one that matches its user name. For example,
-if the URL is `https://user@example.com/foo/bar` a config key match of
-`https://example.com/foo` will be preferred over a config key match of
-`https://user@example.com`.
-+
-All URLs are normalized before attempting any matching (the password part,
-if embedded in the URL, is always ignored for matching purposes) so that
-equivalent URLs that are simply spelled differently will match properly.
-Environment variable settings always override any matches. The URLs that are
-matched against are those given directly to Git commands. This means any URLs
-visited as a result of a redirection do not participate in matching.
-
-ssh.variant::
- Depending on the value of the environment variables `GIT_SSH` or
- `GIT_SSH_COMMAND`, or the config setting `core.sshCommand`, Git
- auto-detects whether to adjust its command-line parameters for use
- with plink or tortoiseplink, as opposed to the default (OpenSSH).
-+
-The config variable `ssh.variant` can be set to override this auto-detection;
-valid values are `ssh`, `plink`, `putty` or `tortoiseplink`. Any other value
-will be treated as normal ssh. This setting can be overridden via the
-environment variable `GIT_SSH_VARIANT`.
-
-i18n.commitEncoding::
- Character encoding the commit messages are stored in; Git itself
- does not care per se, but this information is necessary e.g. when
- importing commits from emails or in the gitk graphical history
- browser (and possibly at other places in the future or in other
- porcelains). See e.g. linkgit:git-mailinfo[1]. Defaults to 'utf-8'.
-
-i18n.logOutputEncoding::
- Character encoding the commit messages are converted to when
- running 'git log' and friends.
-
-imap::
- The configuration variables in the 'imap' section are described
- in linkgit:git-imap-send[1].
-
-index.version::
- Specify the version with which new index files should be
- initialized. This does not affect existing repositories.
-
-init.templateDir::
- Specify the directory from which templates will be copied.
- (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)
-
-instaweb.browser::
- Specify the program that will be used to browse your working
- repository in gitweb. See linkgit:git-instaweb[1].
-
-instaweb.httpd::
- The HTTP daemon command-line to start gitweb on your working
- repository. See linkgit:git-instaweb[1].
-
-instaweb.local::
- If true the web server started by linkgit:git-instaweb[1] will
- be bound to the local IP (127.0.0.1).
-
-instaweb.modulePath::
- The default module path for linkgit:git-instaweb[1] to use
- instead of /usr/lib/apache2/modules. Only used if httpd
- is Apache.
-
-instaweb.port::
- The port number to bind the gitweb httpd to. See
- linkgit:git-instaweb[1].
-
-interactive.singleKey::
- In interactive commands, allow the user to provide one-letter
- input with a single key (i.e., without hitting enter).
- Currently this is used by the `--patch` mode of
- linkgit:git-add[1], linkgit:git-checkout[1], linkgit:git-commit[1],
- linkgit:git-reset[1], and linkgit:git-stash[1]. Note that this
- setting is silently ignored if portable keystroke input
- is not available; requires the Perl module Term::ReadKey.
-
-interactive.diffFilter::
- When an interactive command (such as `git add --patch`) shows
- a colorized diff, git will pipe the diff through the shell
- command defined by this configuration variable. The command may
- mark up the diff further for human consumption, provided that it
- retains a one-to-one correspondence with the lines in the
- original diff. Defaults to disabled (no filtering).
-
-log.abbrevCommit::
- If true, makes linkgit:git-log[1], linkgit:git-show[1], and
- linkgit:git-whatchanged[1] assume `--abbrev-commit`. You may
- override this option with `--no-abbrev-commit`.
-
-log.date::
- Set the default date-time mode for the 'log' command.
- Setting a value for log.date is similar to using 'git log''s
- `--date` option. See linkgit:git-log[1] for details.
-
-log.decorate::
- Print out the ref names of any commits that are shown by the log
- command. If 'short' is specified, the ref name prefixes 'refs/heads/',
- 'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
- specified, the full ref name (including prefix) will be printed.
- If 'auto' is specified, then if the output is going to a terminal,
- the ref names are shown as if 'short' were given, otherwise no ref
- names are shown. This is the same as the `--decorate` option
- of the `git log`.
-
-log.follow::
- If `true`, `git log` will act as if the `--follow` option was used when
- a single <path> is given. This has the same limitations as `--follow`,
- i.e. it cannot be used to follow multiple files and does not work well
- on non-linear history.
-
-log.graphColors::
- A list of colors, separated by commas, that can be used to draw
- history lines in `git log --graph`.
-
-log.showRoot::
- If true, the initial commit will be shown as a big creation event.
- This is equivalent to a diff against an empty tree.
- Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
- normally hide the root commit will now show it. True by default.
-
-log.mailmap::
- If true, makes linkgit:git-log[1], linkgit:git-show[1], and
- linkgit:git-whatchanged[1] assume `--use-mailmap`.
-
-mailinfo.scissors::
- If true, makes linkgit:git-mailinfo[1] (and therefore
- linkgit:git-am[1]) act by default as if the --scissors option
- was provided on the command-line. When active, this features
- removes everything from the message body before a scissors
- line (i.e. consisting mainly of ">8", "8<" and "-").
-
-mailmap.file::
- The location of an augmenting mailmap file. The default
- mailmap, located in the root of the repository, is loaded
- first, then the mailmap file pointed to by this variable.
- The location of the mailmap file may be in a repository
- subdirectory, or somewhere outside of the repository itself.
- See linkgit:git-shortlog[1] and linkgit:git-blame[1].
-
-mailmap.blob::
- Like `mailmap.file`, but consider the value as a reference to a
- blob in the repository. If both `mailmap.file` and
- `mailmap.blob` are given, both are parsed, with entries from
- `mailmap.file` taking precedence. In a bare repository, this
- defaults to `HEAD:.mailmap`. In a non-bare repository, it
- defaults to empty.
-
-man.viewer::
- Specify the programs that may be used to display help in the
- 'man' format. See linkgit:git-help[1].
-
-man.<tool>.cmd::
- Specify the command to invoke the specified man viewer. The
- specified command is evaluated in shell with the man page
- passed as argument. (See linkgit:git-help[1].)
-
-man.<tool>.path::
- Override the path for the given tool that may be used to
- display help in the 'man' format. See linkgit:git-help[1].
-
-include::merge-config.txt[]
-
-mergetool.<tool>.path::
- Override the path for the given tool. This is useful in case
- your tool is not in the PATH.
-
-mergetool.<tool>.cmd::
- Specify the command to invoke the specified merge tool. The
- specified command is evaluated in shell with the following
- variables available: 'BASE' is the name of a temporary file
- containing the common base of the files to be merged, if available;
- 'LOCAL' is the name of a temporary file containing the contents of
- the file on the current branch; 'REMOTE' is the name of a temporary
- file containing the contents of the file from the branch being
- merged; 'MERGED' contains the name of the file to which the merge
- tool should write the results of a successful merge.
-
-mergetool.<tool>.trustExitCode::
- For a custom merge command, specify whether the exit code of
- the merge command can be used to determine whether the merge was
- successful. If this is not set to true then the merge target file
- timestamp is checked and the merge assumed to have been successful
- if the file has been updated, otherwise the user is prompted to
- indicate the success of the merge.
-
-mergetool.meld.hasOutput::
- Older versions of `meld` do not support the `--output` option.
- Git will attempt to detect whether `meld` supports `--output`
- by inspecting the output of `meld --help`. Configuring
- `mergetool.meld.hasOutput` will make Git skip these checks and
- use the configured value instead. Setting `mergetool.meld.hasOutput`
- to `true` tells Git to unconditionally use the `--output` option,
- and `false` avoids using `--output`.
-
-mergetool.keepBackup::
- After performing a merge, the original file with conflict markers
- can be saved as a file with a `.orig` extension. If this variable
- is set to `false` then this file is not preserved. Defaults to
- `true` (i.e. keep the backup files).
-
-mergetool.keepTemporaries::
- When invoking a custom merge tool, Git uses a set of temporary
- files to pass to the tool. If the tool returns an error and this
- variable is set to `true`, then these temporary files will be
- preserved, otherwise they will be removed after the tool has
- exited. Defaults to `false`.
-
-mergetool.writeToTemp::
- Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of
- conflicting files in the worktree by default. Git will attempt
- to use a temporary directory for these files when set `true`.
- Defaults to `false`.
-
-mergetool.prompt::
- Prompt before each invocation of the merge resolution program.
-
-notes.mergeStrategy::
- Which merge strategy to choose by default when resolving notes
- conflicts. Must be one of `manual`, `ours`, `theirs`, `union`, or
- `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE STRATEGIES"
- section of linkgit:git-notes[1] for more information on each strategy.
-
-notes.<name>.mergeStrategy::
- Which merge strategy to choose when doing a notes merge into
- refs/notes/<name>. This overrides the more general
- "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in
- linkgit:git-notes[1] for more information on the available strategies.
-
-notes.displayRef::
- The (fully qualified) refname from which to show notes when
- showing commit messages. The value of this variable can be set
- to a glob, in which case notes from all matching refs will be
- shown. You may also specify this configuration variable
- several times. A warning will be issued for refs that do not
- exist, but a glob that does not match any refs is silently
- ignored.
-+
-This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
-environment variable, which must be a colon separated list of refs or
-globs.
-+
-The effective value of "core.notesRef" (possibly overridden by
-GIT_NOTES_REF) is also implicitly added to the list of refs to be
-displayed.
-
-notes.rewrite.<command>::
- When rewriting commits with <command> (currently `amend` or
- `rebase`) and this variable is set to `true`, Git
- automatically copies your notes from the original to the
- rewritten commit. Defaults to `true`, but see
- "notes.rewriteRef" below.
-
-notes.rewriteMode::
- When copying notes during a rewrite (see the
- "notes.rewrite.<command>" option), determines what to do if
- the target commit already has a note. Must be one of
- `overwrite`, `concatenate`, `cat_sort_uniq`, or `ignore`.
- Defaults to `concatenate`.
-+
-This setting can be overridden with the `GIT_NOTES_REWRITE_MODE`
-environment variable.
-
-notes.rewriteRef::
- When copying notes during a rewrite, specifies the (fully
- qualified) ref whose notes should be copied. The ref may be a
- glob, in which case notes in all matching refs will be copied.
- You may also specify this configuration several times.
-+
-Does not have a default value; you must configure this variable to
-enable note rewriting. Set it to `refs/notes/commits` to enable
-rewriting for the default commit notes.
-+
-This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
-environment variable, which must be a colon separated list of refs or
-globs.
-
-pack.window::
- The size of the window used by linkgit:git-pack-objects[1] when no
- window size is given on the command line. Defaults to 10.
-
-pack.depth::
- The maximum delta depth used by linkgit:git-pack-objects[1] when no
- maximum depth is given on the command line. Defaults to 50.
-
-pack.windowMemory::
- The maximum size of memory that is consumed by each thread
- in linkgit:git-pack-objects[1] for pack window memory when
- no limit is given on the command line. The value can be
- suffixed with "k", "m", or "g". When left unconfigured (or
- set explicitly to 0), there will be no limit.
-
-pack.compression::
- An integer -1..9, indicating the compression level for objects
- in a pack file. -1 is the zlib default. 0 means no
- compression, and 1..9 are various speed/size tradeoffs, 9 being
- slowest. If not set, defaults to core.compression. If that is
- not set, defaults to -1, the zlib default, which is "a default
- compromise between speed and compression (currently equivalent
- to level 6)."
-+
-Note that changing the compression level will not automatically recompress
-all existing objects. You can force recompression by passing the -F option
-to linkgit:git-repack[1].
-
-pack.deltaCacheSize::
- The maximum memory in bytes used for caching deltas in
- linkgit:git-pack-objects[1] before writing them out to a pack.
- This cache is used to speed up the writing object phase by not
- having to recompute the final delta result once the best match
- for all objects is found. Repacking large repositories on machines
- which are tight with memory might be badly impacted by this though,
- especially if this cache pushes the system into swapping.
- A value of 0 means no limit. The smallest size of 1 byte may be
- used to virtually disable this cache. Defaults to 256 MiB.
-
-pack.deltaCacheLimit::
- The maximum size of a delta, that is cached in
- linkgit:git-pack-objects[1]. This cache is used to speed up the
- writing object phase by not having to recompute the final delta
- result once the best match for all objects is found. Defaults to 1000.
-
-pack.threads::
- Specifies the number of threads to spawn when searching for best
- delta matches. This requires that linkgit:git-pack-objects[1]
- be compiled with pthreads otherwise this option is ignored with a
- warning. This is meant to reduce packing time on multiprocessor
- machines. The required amount of memory for the delta search window
- is however multiplied by the number of threads.
- Specifying 0 will cause Git to auto-detect the number of CPU's
- and set the number of threads accordingly.
-
-pack.indexVersion::
- Specify the default pack index version. Valid values are 1 for
- legacy pack index used by Git versions prior to 1.5.2, and 2 for
- the new pack index with capabilities for packs larger than 4 GB
- as well as proper protection against the repacking of corrupted
- packs. Version 2 is the default. Note that version 2 is enforced
- and this config option ignored whenever the corresponding pack is
- larger than 2 GB.
-+
-If you have an old Git that does not understand the version 2 `*.idx` file,
-cloning or fetching over a non native protocol (e.g. "http")
-that will copy both `*.pack` file and corresponding `*.idx` file from the
-other side may give you a repository that cannot be accessed with your
-older version of Git. If the `*.pack` file is smaller than 2 GB, however,
-you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
-the `*.idx` file.
-
-pack.packSizeLimit::
- The maximum size of a pack. This setting only affects
- packing to a file when repacking, i.e. the git:// protocol
- is unaffected. It can be overridden by the `--max-pack-size`
- option of linkgit:git-repack[1]. Reaching this limit results
- in the creation of multiple packfiles; which in turn prevents
- bitmaps from being created.
- The minimum size allowed is limited to 1 MiB.
- The default is unlimited.
- Common unit suffixes of 'k', 'm', or 'g' are
- supported.
-
-pack.useBitmaps::
- When true, git will use pack bitmaps (if available) when packing
- to stdout (e.g., during the server side of a fetch). Defaults to
- true. You should not generally need to turn this off unless
- you are debugging pack bitmaps.
-
-pack.writeBitmaps (deprecated)::
- This is a deprecated synonym for `repack.writeBitmaps`.
-
-pack.writeBitmapHashCache::
- When true, git will include a "hash cache" section in the bitmap
- index (if one is written). This cache can be used to feed git's
- delta heuristics, potentially leading to better deltas between
- bitmapped and non-bitmapped objects (e.g., when serving a fetch
- between an older, bitmapped pack and objects that have been
- pushed since the last gc). The downside is that it consumes 4
- bytes per object of disk space, and that JGit's bitmap
- implementation does not understand it, causing it to complain if
- Git and JGit are used on the same repository. Defaults to false.
-
-pager.<cmd>::
- If the value is boolean, turns on or off pagination of the
- output of a particular Git subcommand when writing to a tty.
- Otherwise, turns on pagination for the subcommand using the
- pager specified by the value of `pager.<cmd>`. If `--paginate`
- or `--no-pager` is specified on the command line, it takes
- precedence over this option. To disable pagination for all
- commands, set `core.pager` or `GIT_PAGER` to `cat`.
-
-pretty.<name>::
- Alias for a --pretty= format string, as specified in
- linkgit:git-log[1]. Any aliases defined here can be used just
- as the built-in pretty formats could. For example,
- running `git config pretty.changelog "format:* %H %s"`
- would cause the invocation `git log --pretty=changelog`
- to be equivalent to running `git log "--pretty=format:* %H %s"`.
- Note that an alias with the same name as a built-in format
- will be silently ignored.
-
-protocol.allow::
- If set, provide a user defined default policy for all protocols which
- don't explicitly have a policy (`protocol.<name>.allow`). By default,
- if unset, known-safe protocols (http, https, git, ssh, file) have a
- default policy of `always`, known-dangerous protocols (ext) have a
- default policy of `never`, and all other protocols have a default
- policy of `user`. Supported policies:
-+
---
+include::config/am.txt[]
-* `always` - protocol is always able to be used.
+include::config/apply.txt[]
-* `never` - protocol is never able to be used.
+include::config/blame.txt[]
-* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is
- either unset or has a value of 1. This policy should be used when you want a
- protocol to be directly usable by the user but don't want it used by commands which
- execute clone/fetch/push commands without user input, e.g. recursive
- submodule initialization.
+include::config/branch.txt[]
---
+include::config/browser.txt[]
-protocol.<name>.allow::
- Set a policy to be used by protocol `<name>` with clone/fetch/push
- commands. See `protocol.allow` above for the available policies.
-+
-The protocol names currently used by git are:
-+
---
- - `file`: any local file-based path (including `file://` URLs,
- or local paths)
-
- - `git`: the anonymous git protocol over a direct TCP
- connection (or proxy, if configured)
-
- - `ssh`: git over ssh (including `host:path` syntax,
- `ssh://`, etc).
-
- - `http`: git over http, both "smart http" and "dumb http".
- Note that this does _not_ include `https`; if you want to configure
- both, you must do so individually.
-
- - any external helpers are named by their protocol (e.g., use
- `hg` to allow the `git-remote-hg` helper)
---
-
-pull.ff::
- By default, Git does not create an extra merge commit when merging
- a commit that is a descendant of the current commit. Instead, the
- tip of the current branch is fast-forwarded. When set to `false`,
- this variable tells Git to create an extra merge commit in such
- a case (equivalent to giving the `--no-ff` option from the command
- line). When set to `only`, only such fast-forward merges are
- allowed (equivalent to giving the `--ff-only` option from the
- command line). This setting overrides `merge.ff` when pulling.
-
-pull.rebase::
- When true, rebase branches on top of the fetched branch, instead
- of merging the default branch from the default remote when "git
- pull" is run. See "branch.<name>.rebase" for setting this on a
- per-branch basis.
-+
-When preserve, also pass `--preserve-merges` along to 'git rebase'
-so that locally committed merge commits will not be flattened
-by running 'git pull'.
-+
-When the value is `interactive`, the rebase is run in interactive mode.
-+
-*NOTE*: this is a possibly dangerous operation; do *not* use
-it unless you understand the implications (see linkgit:git-rebase[1]
-for details).
-
-pull.octopus::
- The default merge strategy to use when pulling multiple branches
- at once.
-
-pull.twohead::
- The default merge strategy to use when pulling a single branch.
-
-push.default::
- Defines the action `git push` should take if no refspec is
- explicitly given. Different values are well-suited for
- specific workflows; for instance, in a purely central workflow
- (i.e. the fetch source is equal to the push destination),
- `upstream` is probably what you want. Possible values are:
-+
---
+include::config/checkout.txt[]
-* `nothing` - do not push anything (error out) unless a refspec is
- explicitly given. This is primarily meant for people who want to
- avoid mistakes by always being explicit.
+include::config/clean.txt[]
-* `current` - push the current branch to update a branch with the same
- name on the receiving end. Works in both central and non-central
- workflows.
+include::config/color.txt[]
-* `upstream` - push the current branch back to the branch whose
- changes are usually integrated into the current branch (which is
- called `@{upstream}`). This mode only makes sense if you are
- pushing to the same repository you would normally pull from
- (i.e. central workflow).
+include::config/column.txt[]
-* `tracking` - This is a deprecated synonym for `upstream`.
+include::config/commit.txt[]
-* `simple` - in centralized workflow, work like `upstream` with an
- added safety to refuse to push if the upstream branch's name is
- different from the local one.
-+
-When pushing to a remote that is different from the remote you normally
-pull from, work as `current`. This is the safest option and is suited
-for beginners.
-+
-This mode has become the default in Git 2.0.
-
-* `matching` - push all branches having the same name on both ends.
- This makes the repository you are pushing to remember the set of
- branches that will be pushed out (e.g. if you always push 'maint'
- and 'master' there and no other branches, the repository you push
- to will have these two branches, and your local 'maint' and
- 'master' will be pushed there).
-+
-To use this mode effectively, you have to make sure _all_ the
-branches you would push out are ready to be pushed out before
-running 'git push', as the whole point of this mode is to allow you
-to push all of the branches in one go. If you usually finish work
-on only one branch and push out the result, while other branches are
-unfinished, this mode is not for you. Also this mode is not
-suitable for pushing into a shared central repository, as other
-people may add new branches there, or update the tip of existing
-branches outside your control.
-+
-This used to be the default, but not since Git 2.0 (`simple` is the
-new default).
-
---
-
-push.followTags::
- If set to true enable `--follow-tags` option by default. You
- may override this configuration at time of push by specifying
- `--no-follow-tags`.
-
-push.gpgSign::
- May be set to a boolean value, or the string 'if-asked'. A true
- value causes all pushes to be GPG signed, as if `--signed` is
- passed to linkgit:git-push[1]. The string 'if-asked' causes
- pushes to be signed if the server supports it, as if
- `--signed=if-asked` is passed to 'git push'. A false value may
- override a value from a lower-priority config file. An explicit
- command-line flag always overrides this config option.
-
-push.recurseSubmodules::
- Make sure all submodule commits used by the revisions to be pushed
- are available on a remote-tracking branch. If the value is 'check'
- then Git will verify that all submodule commits that changed in the
- revisions to be pushed are available on at least one remote of the
- submodule. If any commits are missing, the push will be aborted and
- exit with non-zero status. If the value is 'on-demand' then all
- submodules that changed in the revisions to be pushed will be
- pushed. If on-demand was not able to push all necessary revisions
- it will also be aborted and exit with non-zero status. If the value
- is 'no' then default behavior of ignoring submodules when pushing
- is retained. You may override this configuration at time of push by
- specifying '--recurse-submodules=check|on-demand|no'.
-
-rebase.stat::
- Whether to show a diffstat of what changed upstream since the last
- rebase. False by default.
-
-rebase.autoSquash::
- If set to true enable `--autosquash` option by default.
-
-rebase.autoStash::
- When set to true, automatically create a temporary stash
- before the operation begins, and apply it after the operation
- ends. This means that you can run rebase on a dirty worktree.
- However, use with care: the final stash application after a
- successful rebase might result in non-trivial conflicts.
- Defaults to false.
-
-rebase.missingCommitsCheck::
- If set to "warn", git rebase -i will print a warning if some
- commits are removed (e.g. a line was deleted), however the
- rebase will still proceed. If set to "error", it will print
- the previous warning and stop the rebase, 'git rebase
- --edit-todo' can then be used to correct the error. If set to
- "ignore", no checking is done.
- To drop a commit without warning or error, use the `drop`
- command in the todo-list.
- Defaults to "ignore".
-
-rebase.instructionFormat::
- A format string, as specified in linkgit:git-log[1], to be used for
- the instruction list during an interactive rebase. The format will automatically
- have the long commit hash prepended to the format.
-
-receive.advertiseAtomic::
- By default, git-receive-pack will advertise the atomic push
- capability to its clients. If you don't want to advertise this
- capability, set this variable to false.
-
-receive.advertisePushOptions::
- By default, git-receive-pack will advertise the push options
- capability to its clients. If you don't want to advertise this
- capability, set this variable to false.
-
-receive.autogc::
- By default, git-receive-pack will run "git-gc --auto" after
- receiving data from git-push and updating refs. You can stop
- it by setting this variable to false.
-
-receive.certNonceSeed::
- By setting this variable to a string, `git receive-pack`
- will accept a `git push --signed` and verifies it by using
- a "nonce" protected by HMAC using this string as a secret
- key.
-
-receive.certNonceSlop::
- When a `git push --signed` sent a push certificate with a
- "nonce" that was issued by a receive-pack serving the same
- repository within this many seconds, export the "nonce"
- found in the certificate to `GIT_PUSH_CERT_NONCE` to the
- hooks (instead of what the receive-pack asked the sending
- side to include). This may allow writing checks in
- `pre-receive` and `post-receive` a bit easier. Instead of
- checking `GIT_PUSH_CERT_NONCE_SLOP` environment variable
- that records by how many seconds the nonce is stale to
- decide if they want to accept the certificate, they only
- can check `GIT_PUSH_CERT_NONCE_STATUS` is `OK`.
-
-receive.fsckObjects::
- If it is set to true, git-receive-pack will check all received
- objects. It will abort in the case of a malformed object or a
- broken link. The result of an abort are only dangling objects.
- Defaults to false. If not set, the value of `transfer.fsckObjects`
- is used instead.
-
-receive.fsck.<msg-id>::
- When `receive.fsckObjects` is set to true, errors can be switched
- to warnings and vice versa by configuring the `receive.fsck.<msg-id>`
- setting where the `<msg-id>` is the fsck message ID and the value
- is one of `error`, `warn` or `ignore`. For convenience, fsck prefixes
- the error/warning with the message ID, e.g. "missingEmail: invalid
- author/committer line - missing email" means that setting
- `receive.fsck.missingEmail = ignore` will hide that issue.
-+
-This feature is intended to support working with legacy repositories
-which would not pass pushing when `receive.fsckObjects = true`, allowing
-the host to accept repositories with certain known issues but still catch
-other issues.
-
-receive.fsck.skipList::
- The path to a sorted list of object names (i.e. one SHA-1 per
- line) that are known to be broken in a non-fatal way and should
- be ignored. This feature is useful when an established project
- should be accepted despite early commits containing errors that
- can be safely ignored such as invalid committer email addresses.
- Note: corrupt objects cannot be skipped with this setting.
-
-receive.keepAlive::
- After receiving the pack from the client, `receive-pack` may
- produce no output (if `--quiet` was specified) while processing
- the pack, causing some networks to drop the TCP connection.
- With this option set, if `receive-pack` does not transmit
- any data in this phase for `receive.keepAlive` seconds, it will
- send a short keepalive packet. The default is 5 seconds; set
- to 0 to disable keepalives entirely.
-
-receive.unpackLimit::
- If the number of objects received in a push is below this
- limit then the objects will be unpacked into loose object
- files. However if the number of received objects equals or
- exceeds this limit then the received pack will be stored as
- a pack, after adding any missing delta bases. Storing the
- pack from a push can make the push operation complete faster,
- especially on slow filesystems. If not set, the value of
- `transfer.unpackLimit` is used instead.
-
-receive.maxInputSize::
- If the size of the incoming pack stream is larger than this
- limit, then git-receive-pack will error out, instead of
- accepting the pack file. If not set or set to 0, then the size
- is unlimited.
-
-receive.denyDeletes::
- If set to true, git-receive-pack will deny a ref update that deletes
- the ref. Use this to prevent such a ref deletion via a push.
-
-receive.denyDeleteCurrent::
- If set to true, git-receive-pack will deny a ref update that
- deletes the currently checked out branch of a non-bare repository.
-
-receive.denyCurrentBranch::
- If set to true or "refuse", git-receive-pack will deny a ref update
- to the currently checked out branch of a non-bare repository.
- Such a push is potentially dangerous because it brings the HEAD
- out of sync with the index and working tree. If set to "warn",
- print a warning of such a push to stderr, but allow the push to
- proceed. If set to false or "ignore", allow such pushes with no
- message. Defaults to "refuse".
-+
-Another option is "updateInstead" which will update the working
-tree if pushing into the current branch. This option is
-intended for synchronizing working directories when one side is not easily
-accessible via interactive ssh (e.g. a live web site, hence the requirement
-that the working directory be clean). This mode also comes in handy when
-developing inside a VM to test and fix code on different Operating Systems.
-+
-By default, "updateInstead" will refuse the push if the working tree or
-the index have any difference from the HEAD, but the `push-to-checkout`
-hook can be used to customize this. See linkgit:githooks[5].
-
-receive.denyNonFastForwards::
- If set to true, git-receive-pack will deny a ref update which is
- not a fast-forward. Use this to prevent such an update via a push,
- even if that push is forced. This configuration variable is
- set when initializing a shared repository.
-
-receive.hideRefs::
- This variable is the same as `transfer.hideRefs`, but applies
- only to `receive-pack` (and so affects pushes, but not fetches).
- An attempt to update or delete a hidden ref by `git push` is
- rejected.
-
-receive.updateServerInfo::
- If set to true, git-receive-pack will run git-update-server-info
- after receiving data from git-push and updating refs.
-
-receive.shallowUpdate::
- If set to true, .git/shallow can be updated when new refs
- require new shallow roots. Otherwise those refs are rejected.
-
-remote.pushDefault::
- The remote to push to by default. Overrides
- `branch.<name>.remote` for all branches, and is overridden by
- `branch.<name>.pushRemote` for specific branches.
-
-remote.<name>.url::
- The URL of a remote repository. See linkgit:git-fetch[1] or
- linkgit:git-push[1].
-
-remote.<name>.pushurl::
- The push URL of a remote repository. See linkgit:git-push[1].
-
-remote.<name>.proxy::
- For remotes that require curl (http, https and ftp), the URL to
- the proxy to use for that remote. Set to the empty string to
- disable proxying for that remote.
-
-remote.<name>.proxyAuthMethod::
- For remotes that require curl (http, https and ftp), the method to use for
- authenticating against the proxy in use (probably set in
- `remote.<name>.proxy`). See `http.proxyAuthMethod`.
-
-remote.<name>.fetch::
- The default set of "refspec" for linkgit:git-fetch[1]. See
- linkgit:git-fetch[1].
-
-remote.<name>.push::
- The default set of "refspec" for linkgit:git-push[1]. See
- linkgit:git-push[1].
-
-remote.<name>.mirror::
- If true, pushing to this remote will automatically behave
- as if the `--mirror` option was given on the command line.
-
-remote.<name>.skipDefaultUpdate::
- If true, this remote will be skipped by default when updating
- using linkgit:git-fetch[1] or the `update` subcommand of
- linkgit:git-remote[1].
-
-remote.<name>.skipFetchAll::
- If true, this remote will be skipped by default when updating
- using linkgit:git-fetch[1] or the `update` subcommand of
- linkgit:git-remote[1].
-
-remote.<name>.receivepack::
- The default program to execute on the remote side when pushing. See
- option --receive-pack of linkgit:git-push[1].
-
-remote.<name>.uploadpack::
- The default program to execute on the remote side when fetching. See
- option --upload-pack of linkgit:git-fetch-pack[1].
-
-remote.<name>.tagOpt::
- Setting this value to --no-tags disables automatic tag following when
- fetching from remote <name>. Setting it to --tags will fetch every
- tag from remote <name>, even if they are not reachable from remote
- branch heads. Passing these flags directly to linkgit:git-fetch[1] can
- override this setting. See options --tags and --no-tags of
- linkgit:git-fetch[1].
-
-remote.<name>.vcs::
- Setting this to a value <vcs> will cause Git to interact with
- the remote with the git-remote-<vcs> helper.
-
-remote.<name>.prune::
- When set to true, fetching from this remote by default will also
- remove any remote-tracking references that no longer exist on the
- remote (as if the `--prune` option was given on the command line).
- Overrides `fetch.prune` settings, if any.
-
-remotes.<group>::
- The list of remotes which are fetched by "git remote update
- <group>". See linkgit:git-remote[1].
-
-repack.useDeltaBaseOffset::
- By default, linkgit:git-repack[1] creates packs that use
- delta-base offset. If you need to share your repository with
- Git older than version 1.4.4, either directly or via a dumb
- protocol such as http, then you need to set this option to
- "false" and repack. Access from old Git versions over the
- native protocol are unaffected by this option.
-
-repack.packKeptObjects::
- If set to true, makes `git repack` act as if
- `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
- details. Defaults to `false` normally, but `true` if a bitmap
- index is being written (either via `--write-bitmap-index` or
- `repack.writeBitmaps`).
-
-repack.writeBitmaps::
- When true, git will write a bitmap index when packing all
- objects to disk (e.g., when `git repack -a` is run). This
- index can speed up the "counting objects" phase of subsequent
- packs created for clones and fetches, at the cost of some disk
- space and extra time spent on the initial repack. This has
- no effect if multiple packfiles are created.
- Defaults to false.
-
-rerere.autoUpdate::
- When set to true, `git-rerere` updates the index with the
- resulting contents after it cleanly resolves conflicts using
- previously recorded resolution. Defaults to false.
-
-rerere.enabled::
- Activate recording of resolved conflicts, so that identical
- conflict hunks can be resolved automatically, should they be
- encountered again. By default, linkgit:git-rerere[1] is
- enabled if there is an `rr-cache` directory under the
- `$GIT_DIR`, e.g. if "rerere" was previously used in the
- repository.
-
-sendemail.identity::
- A configuration identity. When given, causes values in the
- 'sendemail.<identity>' subsection to take precedence over
- values in the 'sendemail' section. The default identity is
- the value of `sendemail.identity`.
-
-sendemail.smtpEncryption::
- See linkgit:git-send-email[1] for description. Note that this
- setting is not subject to the 'identity' mechanism.
-
-sendemail.smtpssl (deprecated)::
- Deprecated alias for 'sendemail.smtpEncryption = ssl'.
-
-sendemail.smtpsslcertpath::
- Path to ca-certificates (either a directory or a single file).
- Set it to an empty string to disable certificate verification.
-
-sendemail.<identity>.*::
- Identity-specific versions of the 'sendemail.*' parameters
- found below, taking precedence over those when the this
- identity is selected, through command-line or
- `sendemail.identity`.
-
-sendemail.aliasesFile::
-sendemail.aliasFileType::
-sendemail.annotate::
-sendemail.bcc::
-sendemail.cc::
-sendemail.ccCmd::
-sendemail.chainReplyTo::
-sendemail.confirm::
-sendemail.envelopeSender::
-sendemail.from::
-sendemail.multiEdit::
-sendemail.signedoffbycc::
-sendemail.smtpPass::
-sendemail.suppresscc::
-sendemail.suppressFrom::
-sendemail.to::
-sendemail.smtpDomain::
-sendemail.smtpServer::
-sendemail.smtpServerPort::
-sendemail.smtpServerOption::
-sendemail.smtpUser::
-sendemail.thread::
-sendemail.transferEncoding::
-sendemail.validate::
-sendemail.xmailer::
- See linkgit:git-send-email[1] for description.
-
-sendemail.signedoffcc (deprecated)::
- Deprecated alias for `sendemail.signedoffbycc`.
-
-showbranch.default::
- The default set of branches for linkgit:git-show-branch[1].
- See linkgit:git-show-branch[1].
-
-splitIndex.maxPercentChange::
- When the split index feature is used, this specifies the
- percent of entries the split index can contain compared to the
- total number of entries in both the split index and the shared
- index before a new shared index is written.
- The value should be between 0 and 100. If the value is 0 then
- a new shared index is always written, if it is 100 a new
- shared index is never written.
- By default the value is 20, so a new shared index is written
- if the number of entries in the split index would be greater
- than 20 percent of the total number of entries.
- See linkgit:git-update-index[1].
-
-splitIndex.sharedIndexExpire::
- When the split index feature is used, shared index files that
- were not modified since the time this variable specifies will
- be removed when a new shared index file is created. The value
- "now" expires all entries immediately, and "never" suppresses
- expiration altogether.
- The default value is "2.weeks.ago".
- Note that a shared index file is considered modified (for the
- purpose of expiration) each time a new split-index file is
- either created based on it or read from it.
- See linkgit:git-update-index[1].
-
-status.relativePaths::
- By default, linkgit:git-status[1] shows paths relative to the
- current directory. Setting this variable to `false` shows paths
- relative to the repository root (this was the default for Git
- prior to v1.5.4).
-
-status.short::
- Set to true to enable --short by default in linkgit:git-status[1].
- The option --no-short takes precedence over this variable.
-
-status.branch::
- Set to true to enable --branch by default in linkgit:git-status[1].
- The option --no-branch takes precedence over this variable.
-
-status.displayCommentPrefix::
- If set to true, linkgit:git-status[1] will insert a comment
- prefix before each output line (starting with
- `core.commentChar`, i.e. `#` by default). This was the
- behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
- Defaults to false.
-
-status.showUntrackedFiles::
- By default, linkgit:git-status[1] and linkgit:git-commit[1] show
- files which are not currently tracked by Git. Directories which
- contain only untracked files, are shown with the directory name
- only. Showing untracked files means that Git needs to lstat() all
- the files in the whole repository, which might be slow on some
- systems. So, this variable controls how the commands displays
- the untracked files. Possible values are:
-+
---
-* `no` - Show no untracked files.
-* `normal` - Show untracked files and directories.
-* `all` - Show also individual files in untracked directories.
---
-+
-If this variable is not specified, it defaults to 'normal'.
-This variable can be overridden with the -u|--untracked-files option
-of linkgit:git-status[1] and linkgit:git-commit[1].
-
-status.submoduleSummary::
- Defaults to false.
- If this is set to a non zero number or true (identical to -1 or an
- unlimited number), the submodule summary will be enabled and a
- summary of commits for modified submodules will be shown (see
- --summary-limit option of linkgit:git-submodule[1]). Please note
- that the summary output command will be suppressed for all
- submodules when `diff.ignoreSubmodules` is set to 'all' or only
- for those submodules where `submodule.<name>.ignore=all`. The only
- exception to that rule is that status and commit will show staged
- submodule changes. To
- also view the summary for ignored submodules you can either use
- the --ignore-submodules=dirty command-line option or the 'git
- submodule summary' command, which shows a similar output but does
- not honor these settings.
-
-stash.showPatch::
- If this is set to true, the `git stash show` command without an
- option will show the stash in patch form. Defaults to false.
- See description of 'show' command in linkgit:git-stash[1].
-
-stash.showStat::
- If this is set to true, the `git stash show` command without an
- option will show diffstat of the stash. Defaults to true.
- See description of 'show' command in linkgit:git-stash[1].
-
-submodule.<name>.url::
- The URL for a submodule. This variable is copied from the .gitmodules
- file to the git config via 'git submodule init'. The user can change
- the configured URL before obtaining the submodule via 'git submodule
- update'. After obtaining the submodule, the presence of this variable
- is used as a sign whether the submodule is of interest to git commands.
- See linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
-
-submodule.<name>.update::
- The default update procedure for a submodule. This variable
- is populated by `git submodule init` from the
- linkgit:gitmodules[5] file. See description of 'update'
- command in linkgit:git-submodule[1].
-
-submodule.<name>.branch::
- The remote branch name for a submodule, used by `git submodule
- update --remote`. Set this option to override the value found in
- the `.gitmodules` file. See linkgit:git-submodule[1] and
- linkgit:gitmodules[5] for details.
-
-submodule.<name>.fetchRecurseSubmodules::
- This option can be used to control recursive fetching of this
- submodule. It can be overridden by using the --[no-]recurse-submodules
- command-line option to "git fetch" and "git pull".
- This setting will override that from in the linkgit:gitmodules[5]
- file.
-
-submodule.<name>.ignore::
- Defines under what circumstances "git status" and the diff family show
- a submodule as modified. When set to "all", it will never be considered
- modified (but it will nonetheless show up in the output of status and
- commit when it has been staged), "dirty" will ignore all changes
- to the submodules work tree and
- takes only differences between the HEAD of the submodule and the commit
- recorded in the superproject into account. "untracked" will additionally
- let submodules with modified tracked files in their work tree show up.
- Using "none" (the default when this option is not set) also shows
- submodules that have untracked files in their work tree as changed.
- This setting overrides any setting made in .gitmodules for this submodule,
- both settings can be overridden on the command line by using the
- "--ignore-submodules" option. The 'git submodule' commands are not
- affected by this setting.
-
-submodule.fetchJobs::
- Specifies how many submodules are fetched/cloned at the same time.
- A positive integer allows up to that number of submodules fetched
- in parallel. A value of 0 will give some reasonable default.
- If unset, it defaults to 1.
-
-submodule.alternateLocation::
- Specifies how the submodules obtain alternates when submodules are
- cloned. Possible values are `no`, `superproject`.
- By default `no` is assumed, which doesn't add references. When the
- value is set to `superproject` the submodule to be cloned computes
- its alternates location relative to the superprojects alternate.
-
-submodule.alternateErrorStrategy::
- Specifies how to treat errors with the alternates for a submodule
- as computed via `submodule.alternateLocation`. Possible values are
- `ignore`, `info`, `die`. Default is `die`.
-
-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.
-
-tar.umask::
- This variable can be used to restrict the permission bits of
- tar archive entries. The default is 0002, which turns off the
- world write bit. The special value "user" indicates that the
- archiving user's umask will be used instead. See umask(2) and
- linkgit:git-archive[1].
-
-transfer.fsckObjects::
- When `fetch.fsckObjects` or `receive.fsckObjects` are
- not set, the value of this variable is used instead.
- Defaults to false.
-
-transfer.hideRefs::
- String(s) `receive-pack` and `upload-pack` use to decide which
- refs to omit from their initial advertisements. Use more than
- one definition to specify multiple prefix strings. A ref that is
- under the hierarchies listed in the value of this variable is
- excluded, and is hidden when responding to `git push` or `git
- fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for
- program-specific versions of this config.
-+
-You may also include a `!` in front of the ref name to negate the entry,
-explicitly exposing it, even if an earlier entry marked it as hidden.
-If you have multiple hideRefs values, later entries override earlier ones
-(and entries in more-specific config files override less-specific ones).
-+
-If a namespace is in use, the namespace prefix is stripped from each
-reference before it is matched against `transfer.hiderefs` patterns.
-For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
-the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
-is omitted from the advertisements but `refs/heads/master` and
-`refs/namespaces/bar/refs/heads/master` are still advertised as so-called
-"have" lines. In order to match refs before stripping, add a `^` in front of
-the ref name. If you combine `!` and `^`, `!` must be specified first.
-+
-Even if you hide refs, a client may still be able to steal the target
-objects via the techniques described in the "SECURITY" section of the
-linkgit:gitnamespaces[7] man page; it's best to keep private data in a
-separate repository.
-
-transfer.unpackLimit::
- When `fetch.unpackLimit` or `receive.unpackLimit` are
- not set, the value of this variable is used instead.
- The default value is 100.
-
-uploadarchive.allowUnreachable::
- If true, allow clients to use `git archive --remote` to request
- any tree, whether reachable from the ref tips or not. See the
- discussion in the "SECURITY" section of
- linkgit:git-upload-archive[1] for more details. Defaults to
- `false`.
-
-uploadpack.hideRefs::
- This variable is the same as `transfer.hideRefs`, but applies
- only to `upload-pack` (and so affects only fetches, not pushes).
- An attempt to fetch a hidden ref by `git fetch` will fail. See
- also `uploadpack.allowTipSHA1InWant`.
-
-uploadpack.allowTipSHA1InWant::
- When `uploadpack.hideRefs` is in effect, allow `upload-pack`
- to accept a fetch request that asks for an object at the tip
- of a hidden ref (by default, such a request is rejected).
- See also `uploadpack.hideRefs`. Even if this is false, a client
- may be able to steal objects via the techniques described in the
- "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
- best to keep private data in a separate repository.
-
-uploadpack.allowReachableSHA1InWant::
- Allow `upload-pack` to accept a fetch request that asks for an
- object that is reachable from any ref tip. However, note that
- calculating object reachability is computationally expensive.
- Defaults to `false`. Even if this is false, a client may be able
- to steal objects via the techniques described in the "SECURITY"
- section of the linkgit:gitnamespaces[7] man page; it's best to
- keep private data in a separate repository.
-
-uploadpack.allowAnySHA1InWant::
- Allow `upload-pack` to accept a fetch request that asks for any
- object at all.
- Defaults to `false`.
-
-uploadpack.keepAlive::
- When `upload-pack` has started `pack-objects`, there may be a
- quiet period while `pack-objects` prepares the pack. Normally
- it would output progress information, but if `--quiet` was used
- for the fetch, `pack-objects` will output nothing at all until
- the pack data begins. Some clients and networks may consider
- the server to be hung and give up. Setting this option instructs
- `upload-pack` to send an empty keepalive packet every
- `uploadpack.keepAlive` seconds. Setting this option to 0
- disables keepalive packets entirely. The default is 5 seconds.
-
-uploadpack.packObjectsHook::
- If this option is set, when `upload-pack` would run
- `git pack-objects` to create a packfile for a client, it will
- run this shell command instead. The `pack-objects` command and
- arguments it _would_ have run (including the `git pack-objects`
- at the beginning) are appended to the shell command. The stdin
- and stdout of the hook are treated as if `pack-objects` itself
- was run. I.e., `upload-pack` will feed input intended for
- `pack-objects` to the hook, and expects a completed packfile on
- stdout.
-+
-Note that this configuration variable is ignored if it is seen in the
-repository-level config (this is a safety measure against fetching from
-untrusted repositories).
-
-url.<base>.insteadOf::
- Any URL that starts with this value will be rewritten to
- start, instead, with <base>. In cases where some site serves a
- large number of repositories, and serves them with multiple
- access methods, and some users need to use different access
- methods, this feature allows people to specify any of the
- equivalent URLs and have Git automatically rewrite the URL to
- the best alternative for the particular user, even for a
- never-before-seen repository on the site. When more than one
- insteadOf strings match a given URL, the longest match is used.
-
-url.<base>.pushInsteadOf::
- Any URL that starts with this value will not be pushed to;
- instead, it will be rewritten to start with <base>, and the
- resulting URL will be pushed to. In cases where some site serves
- a large number of repositories, and serves them with multiple
- access methods, some of which do not allow push, this feature
- allows people to specify a pull-only URL and have Git
- automatically use an appropriate URL to push, even for a
- never-before-seen repository on the site. When more than one
- pushInsteadOf strings match a given URL, the longest match is
- used. If a remote has an explicit pushurl, Git will ignore this
- setting for that remote.
-
-user.email::
- Your email address to be recorded in any newly created commits.
- Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
- `EMAIL` environment variables. See linkgit:git-commit-tree[1].
-
-user.name::
- Your full name to be recorded in any newly created commits.
- Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
- environment variables. See linkgit:git-commit-tree[1].
-
-user.useConfigOnly::
- Instruct Git to avoid trying to guess defaults for `user.email`
- and `user.name`, and instead retrieve the values only from the
- configuration. For example, if you have multiple email addresses
- and would like to use a different one for each repository, then
- with this configuration option set to `true` in the global config
- along with a name, Git will prompt you to set up an email before
- making new commits in a newly cloned repository.
- Defaults to `false`.
-
-user.signingKey::
- If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
- key you want it to automatically when creating a signed tag or
- commit, you can override the default selection with this variable.
- This option is passed unchanged to gpg's --local-user parameter,
- so you may specify a key using any method that gpg supports.
-
-versionsort.prereleaseSuffix (deprecated)::
- Deprecated alias for `versionsort.suffix`. Ignored if
- `versionsort.suffix` is set.
-
-versionsort.suffix::
- Even when version sort is used in linkgit:git-tag[1], tagnames
- with the same base version but different suffixes are still sorted
- lexicographically, resulting e.g. in prerelease tags appearing
- after the main release (e.g. "1.0-rc1" after "1.0"). This
- variable can be specified to determine the sorting order of tags
- with different suffixes.
-+
-By specifying a single suffix in this variable, any tagname containing
-that suffix will appear before the corresponding main release. E.g. if
-the variable is set to "-rc", then all "1.0-rcX" tags will appear before
-"1.0". If specified multiple times, once per suffix, then the order of
-suffixes in the configuration will determine the sorting order of tagnames
-with those suffixes. E.g. if "-pre" appears before "-rc" in the
-configuration, then all "1.0-preX" tags will be listed before any
-"1.0-rcX" tags. The placement of the main release tag relative to tags
-with various suffixes can be determined by specifying the empty suffix
-among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and
-"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
-are listed first, followed by "v4.8", then "v4.8-ckX" and finally
-"v4.8-bfsX".
-+
-If more than one suffixes match the same tagname, then that tagname will
-be sorted according to the suffix which starts at the earliest position in
-the tagname. If more than one different matching suffixes start at
-that earliest position, then that tagname will be sorted according to the
-longest of those suffixes.
-The sorting order between different suffixes is undefined if they are
-in multiple config files.
-
-web.browser::
- Specify a web browser that may be used by some commands.
- Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
- may use it.
+include::config/credential.txt[]
+
+include::config/completion.txt[]
+
+include::config/diff.txt[]
+
+include::config/difftool.txt[]
+
+include::config/fastimport.txt[]
+
+include::config/fetch.txt[]
+
+include::config/format.txt[]
+
+include::config/filter.txt[]
+
+include::config/fsck.txt[]
+
+include::config/gc.txt[]
+
+include::config/gitcvs.txt[]
+
+include::config/gitweb.txt[]
+
+include::config/grep.txt[]
+
+include::config/gpg.txt[]
+
+include::config/gui.txt[]
+
+include::config/guitool.txt[]
+
+include::config/help.txt[]
+
+include::config/http.txt[]
+
+include::config/i18n.txt[]
+
+include::config/imap.txt[]
+
+include::config/index.txt[]
+
+include::config/init.txt[]
+
+include::config/instaweb.txt[]
+
+include::config/interactive.txt[]
+
+include::config/log.txt[]
+
+include::config/mailinfo.txt[]
+
+include::config/mailmap.txt[]
+
+include::config/man.txt[]
+
+include::config/merge.txt[]
+
+include::config/mergetool.txt[]
+
+include::config/notes.txt[]
+
+include::config/pack.txt[]
+
+include::config/pager.txt[]
+
+include::config/pretty.txt[]
+
+include::config/protocol.txt[]
+
+include::config/pull.txt[]
+
+include::config/push.txt[]
+
+include::config/rebase.txt[]
+
+include::config/receive.txt[]
+
+include::config/remote.txt[]
+
+include::config/remotes.txt[]
+
+include::config/repack.txt[]
+
+include::config/rerere.txt[]
+
+include::config/reset.txt[]
+
+include::config/sendemail.txt[]
+
+include::config/sequencer.txt[]
+
+include::config/showbranch.txt[]
+
+include::config/splitindex.txt[]
+
+include::config/ssh.txt[]
+
+include::config/status.txt[]
+
+include::config/stash.txt[]
+
+include::config/submodule.txt[]
+
+include::config/tag.txt[]
+
+include::config/transfer.txt[]
+
+include::config/uploadarchive.txt[]
+
+include::config/uploadpack.txt[]
+
+include::config/url.txt[]
+
+include::config/user.txt[]
+
+include::config/versionsort.txt[]
+
+include::config/web.txt[]
+
+include::config/worktree.txt[]
diff --git a/en/diff-config.txt b/en/diff-config.txt
deleted file mode 100644
index cbce8ec63841e8631f7122dae6e084b15e16832d..0000000000000000000000000000000000000000
--- a/en/diff-config.txt
+++ /dev/null
@@ -1,206 +0,0 @@
-diff.autoRefreshIndex::
- When using 'git diff' to compare with work tree
- files, do not consider stat-only change as changed.
- Instead, silently run `git update-index --refresh` to
- update the cached stat information for paths whose
- contents in the work tree match the contents in the
- index. This option defaults to true. Note that this
- affects only 'git diff' Porcelain, and not lower level
- 'diff' commands such as 'git diff-files'.
-
-diff.dirstat::
- A comma separated list of `--dirstat` parameters specifying the
- default behavior of the `--dirstat` option to linkgit:git-diff[1]`
- and friends. The defaults can be overridden on the command line
- (using `--dirstat=<param1,param2,...>`). The fallback defaults
- (when not changed by `diff.dirstat`) are `changes,noncumulative,3`.
- The following parameters are available:
-+
---
-`changes`;;
- Compute the dirstat numbers by counting the lines that have been
- removed from the source, or added to the destination. This ignores
- the amount of pure code movements within a file. In other words,
- rearranging lines in a file is not counted as much as other changes.
- This is the default behavior when no parameter is given.
-`lines`;;
- Compute the dirstat numbers by doing the regular line-based diff
- analysis, and summing the removed/added line counts. (For binary
- files, count 64-byte chunks instead, since binary files have no
- natural concept of lines). This is a more expensive `--dirstat`
- behavior than the `changes` behavior, but it does count rearranged
- lines within a file as much as other changes. The resulting output
- is consistent with what you get from the other `--*stat` options.
-`files`;;
- Compute the dirstat numbers by counting the number of files changed.
- Each changed file counts equally in the dirstat analysis. This is
- the computationally cheapest `--dirstat` behavior, since it does
- not have to look at the file contents at all.
-`cumulative`;;
- Count changes in a child directory for the parent directory as well.
- Note that when using `cumulative`, the sum of the percentages
- reported may exceed 100%. The default (non-cumulative) behavior can
- be specified with the `noncumulative` parameter.
-<limit>;;
- An integer parameter specifies a cut-off percent (3% by default).
- Directories contributing less than this percentage of the changes
- are not shown in the output.
---
-+
-Example: The following will count changed files, while ignoring
-directories with less than 10% of the total amount of changed files,
-and accumulating child directory counts in the parent directories:
-`files,10,cumulative`.
-
-diff.statGraphWidth::
- Limit the width of the graph part in --stat output. If set, applies
- to all commands generating --stat output except format-patch.
-
-diff.context::
- Generate diffs with <n> lines of context instead of the default
- of 3. This value is overridden by the -U option.
-
-diff.interHunkContext::
- Show the context between diff hunks, up to the specified number
- of lines, thereby fusing the hunks that are close to each other.
- This value serves as the default for the `--inter-hunk-context`
- command line option.
-
-diff.external::
- If this config variable is set, diff generation is not
- performed using the internal diff machinery, but using the
- given command. Can be overridden with the `GIT_EXTERNAL_DIFF'
- environment variable. The command is called with parameters
- as described under "git Diffs" in linkgit:git[1]. Note: if
- you want to use an external diff program only on a subset of
- your files, you might want to use linkgit:gitattributes[5] instead.
-
-diff.ignoreSubmodules::
- Sets the default value of --ignore-submodules. Note that this
- affects only 'git diff' Porcelain, and not lower level 'diff'
- commands such as 'git diff-files'. 'git checkout' also honors
- this setting when reporting uncommitted changes. Setting it to
- 'all' disables the submodule summary normally shown by 'git commit'
- and 'git status' when `status.submoduleSummary` is set unless it is
- overridden by using the --ignore-submodules command-line option.
- The 'git submodule' commands are not affected by this setting.
-
-diff.mnemonicPrefix::
- If set, 'git diff' uses a prefix pair that is different from the
- standard "a/" and "b/" depending on what is being compared. When
- this configuration is in effect, reverse diff output also swaps
- the order of the prefixes:
-`git diff`;;
- compares the (i)ndex and the (w)ork tree;
-`git diff HEAD`;;
- compares a (c)ommit and the (w)ork tree;
-`git diff --cached`;;
- compares a (c)ommit and the (i)ndex;
-`git diff HEAD:file1 file2`;;
- compares an (o)bject and a (w)ork tree entity;
-`git diff --no-index a b`;;
- compares two non-git things (1) and (2).
-
-diff.noprefix::
- If set, 'git diff' does not show any source or destination prefix.
-
-diff.orderFile::
- File indicating how to order files within a diff.
- See the '-O' option to linkgit:git-diff[1] for details.
- If `diff.orderFile` is a relative pathname, it is treated as
- relative to the top of the working tree.
-
-diff.renameLimit::
- The number of files to consider when performing the copy/rename
- detection; equivalent to the 'git diff' option `-l`.
-
-diff.renames::
- Whether and how Git detects renames. If set to "false",
- rename detection is disabled. If set to "true", basic rename
- detection is enabled. If set to "copies" or "copy", Git will
- detect copies, as well. Defaults to true. Note that this
- affects only 'git diff' Porcelain like linkgit:git-diff[1] and
- linkgit:git-log[1], and not lower level commands such as
- linkgit:git-diff-files[1].
-
-diff.suppressBlankEmpty::
- A boolean to inhibit the standard behavior of printing a space
- before each empty output line. Defaults to false.
-
-diff.submodule::
- Specify the format in which differences in submodules are
- shown. The "short" format just shows the names of the commits
- at the beginning and end of the range. The "log" format lists
- the commits in the range like linkgit:git-submodule[1] `summary`
- does. The "diff" format shows an inline diff of the changed
- contents of the submodule. Defaults to "short".
-
-diff.wordRegex::
- A POSIX Extended Regular Expression used to determine what is a "word"
- when performing word-by-word difference calculations. Character
- sequences that match the regular expression are "words", all other
- characters are *ignorable* whitespace.
-
-diff.<driver>.command::
- The custom diff driver command. See linkgit:gitattributes[5]
- for details.
-
-diff.<driver>.xfuncname::
- The regular expression that the diff driver should use to
- recognize the hunk header. A built-in pattern may also be used.
- See linkgit:gitattributes[5] for details.
-
-diff.<driver>.binary::
- Set this option to true to make the diff driver treat files as
- binary. See linkgit:gitattributes[5] for details.
-
-diff.<driver>.textconv::
- The command that the diff driver should call to generate the
- text-converted version of a file. The result of the
- conversion is used to generate a human-readable diff. See
- linkgit:gitattributes[5] for details.
-
-diff.<driver>.wordRegex::
- The regular expression that the diff driver should use to
- split words in a line. See linkgit:gitattributes[5] for
- details.
-
-diff.<driver>.cachetextconv::
- Set this option to true to make the diff driver cache the text
- conversion outputs. See linkgit:gitattributes[5] for details.
-
-diff.tool::
- Controls which diff tool is used by linkgit:git-difftool[1].
- This variable overrides the value configured in `merge.tool`.
- The list below shows the valid built-in values.
- Any other value is treated as a custom diff tool and requires
- that a corresponding difftool.<tool>.cmd variable is defined.
-
-include::mergetools-diff.txt[]
-
-diff.indentHeuristic::
- Set this option to `true` to enable experimental heuristics
- that shift diff hunk boundaries to make patches easier to read.
-
-diff.algorithm::
- Choose a diff algorithm. The variants are as follows:
-+
---
-`default`, `myers`;;
- The basic greedy diff algorithm. Currently, this is the default.
-`minimal`;;
- Spend extra time to make sure the smallest possible diff is
- produced.
-`patience`;;
- Use "patience diff" algorithm when generating patches.
-`histogram`;;
- This algorithm extends the patience algorithm to "support
- low-occurrence common elements".
---
-+
-
-diff.wsErrorHighlight::
- A comma separated list of `old`, `new`, `context`, that
- specifies how whitespace errors on lines are highlighted
- with `color.diff.whitespace`. Can be overridden by the
- command line option `--ws-error-highlight=<kind>`
diff --git a/en/diff-format.txt b/en/diff-format.txt
index c4edc5accf655643740d7f1a0597e7409d72957e..24b924015524146a5eb2bf88a03a6a2a93584ade 100644
--- a/en/diff-format.txt
+++ b/en/diff-format.txt
@@ -26,12 +26,12 @@ line per changed file.
An output line is formatted this way:
------------------------------------------------
-in-place edit :100644 100644 bcd1234... 0123456... M file0
-copy-edit :100644 100644 abcd123... 1234567... C68 file1 file2
-rename-edit :100644 100644 abcd123... 1234567... R86 file1 file3
-create :000000 100644 0000000... 1234567... A file4
-delete :100644 000000 1234567... 0000000... D file5
-unmerged :000000 000000 0000000... 0000000... U file6
+in-place edit :100644 100644 bcd1234 0123456 M file0
+copy-edit :100644 100644 abcd123 1234567 C68 file1 file2
+rename-edit :100644 100644 abcd123 1234567 R86 file1 file3
+create :000000 100644 0000000 1234567 A file4
+delete :100644 000000 1234567 0000000 D file5
+unmerged :000000 000000 0000000 0000000 U file6
------------------------------------------------
That is, from the left to the right:
@@ -75,7 +75,7 @@ and it is out of sync with the index.
Example:
------------------------------------------------
-:100644 100644 5be4a4...... 000000...... M file.c
+:100644 100644 5be4a4a 0000000 M file.c
------------------------------------------------
Without the `-z` option, pathnames with "unusual" characters are
@@ -100,7 +100,7 @@ from the format described above in the following way:
Example:
------------------------------------------------
-::100644 100644 100644 fabadb8... cc95eb0... 4866510... MM describe.c
+::100644 100644 100644 fabadb8 cc95eb0 4866510 MM describe.c
------------------------------------------------
Note that 'combined diff' lists only files which were modified from
diff --git a/en/diff-options.txt b/en/diff-options.txt
index 89cc0f48deef7152d59f4d4665ff3179ed8e4315..554a34080d7081da917cd54cd34eceb7bf4cd95c 100644
--- a/en/diff-options.txt
+++ b/en/diff-options.txt
@@ -63,7 +63,12 @@ ifndef::git-format-patch[]
Synonym for `-p --raw`.
endif::git-format-patch[]
-include::diff-heuristic-options.txt[]
+--indent-heuristic::
+ Enable the heuristic that shifts diff hunk boundaries to make patches
+ easier to read. This is the default.
+
+--no-indent-heuristic::
+ Disable the indent heuristic.
--minimal::
Spend extra time to make sure the smallest possible
@@ -75,6 +80,16 @@ include::diff-heuristic-options.txt[]
--histogram::
Generate a diff using the "histogram diff" algorithm.
+--anchored=<text>::
+ Generate a diff using the "anchored diff" algorithm.
++
+This option may be specified more than once.
++
+If a line exists in both the source and destination, exists only once,
+and starts with this text, this algorithm attempts to prevent it from
+appearing as a deletion or addition in the output. It uses the "patience
+diff" algorithm internally.
+
--diff-algorithm={patience|minimal|histogram|myers}::
Choose a diff algorithm. The variants are as follows:
+
@@ -91,7 +106,7 @@ include::diff-heuristic-options.txt[]
low-occurrence common elements".
--
+
-For instance, if you configured diff.algorithm variable to a
+For instance, if you configured the `diff.algorithm` variable to a
non-default value and want to use the default one, then you
have to use `--diff-algorithm=default` option.
@@ -113,6 +128,14 @@ have to use `--diff-algorithm=default` option.
These parameters can also be set individually with `--stat-width=<width>`,
`--stat-name-width=<name-width>` and `--stat-count=<count>`.
+--compact-summary::
+ Output a condensed summary of extended header information such
+ as file creations or deletions ("new" or "gone", optionally "+l"
+ if it's a symlink) and mode changes ("+x" or "-x" for adding
+ or removing executable bit respectively) in diffstat. The
+ information is put between the filename part and the graph
+ part. Implies `--stat`.
+
--numstat::
Similar to `--stat`, but shows number of added and
deleted lines in decimal notation and pathname without
@@ -231,6 +254,81 @@ ifdef::git-diff[]
endif::git-diff[]
It is the same as `--color=never`.
+--color-moved[=<mode>]::
+ Moved lines of code are colored differently.
+ifdef::git-diff[]
+ It can be changed by the `diff.colorMoved` configuration setting.
+endif::git-diff[]
+ The <mode> defaults to 'no' if the option is not given
+ and to 'zebra' if the option with no mode is given.
+ The mode must be one of:
++
+--
+no::
+ Moved lines are not highlighted.
+default::
+ Is a synonym for `zebra`. This may change to a more sensible mode
+ in the future.
+plain::
+ Any line that is added in one location and was removed
+ in another location will be colored with 'color.diff.newMoved'.
+ Similarly 'color.diff.oldMoved' will be used for removed lines
+ that are added somewhere else in the diff. This mode picks up any
+ moved line, but it is not very useful in a review to determine
+ if a block of code was moved without permutation.
+blocks::
+ Blocks of moved text of at least 20 alphanumeric characters
+ are detected greedily. The detected blocks are
+ painted using either the 'color.diff.{old,new}Moved' color.
+ Adjacent blocks cannot be told apart.
+zebra::
+ Blocks of moved text are detected as in 'blocks' mode. The blocks
+ are painted using either the 'color.diff.{old,new}Moved' color or
+ 'color.diff.{old,new}MovedAlternative'. The change between
+ the two colors indicates that a new block was detected.
+dimmed-zebra::
+ Similar to 'zebra', but additional dimming of uninteresting parts
+ of moved code is performed. The bordering lines of two adjacent
+ blocks are considered interesting, the rest is uninteresting.
+ `dimmed_zebra` is a deprecated synonym.
+--
+
+--no-color-moved::
+ Turn off move detection. This can be used to override configuration
+ settings. It is the same as `--color-moved=no`.
+
+--color-moved-ws=<modes>::
+ This configures how whitespace is ignored when performing the
+ move detection for `--color-moved`.
+ifdef::git-diff[]
+ It can be set by the `diff.colorMovedWS` configuration setting.
+endif::git-diff[]
+ These modes can be given as a comma separated list:
++
+--
+no::
+ Do not ignore whitespace when performing move detection.
+ignore-space-at-eol::
+ Ignore changes in whitespace at EOL.
+ignore-space-change::
+ Ignore changes in amount of whitespace. This ignores whitespace
+ at line end, and considers all other sequences of one or
+ more whitespace characters to be equivalent.
+ignore-all-space::
+ Ignore whitespace when comparing lines. This ignores differences
+ even if one line has whitespace where the other line has none.
+allow-indentation-change::
+ Initially ignore any whitespace in the move detection, then
+ group the moved code blocks only into a block if the change in
+ whitespace is the same per line. This is incompatible with the
+ other modes.
+--
+
+--no-color-moved-ws::
+ Do not ignore whitespace when performing move detection. This can be
+ used to override configuration settings. It is the same as
+ `--color-moved-ws=no`.
+
--word-diff[=<mode>]::
Show a word diff, using the <mode> to delimit changed words.
By default, words are delimited by whitespace; see
@@ -293,22 +391,21 @@ ifndef::git-format-patch[]
Warn if changes introduce conflict markers or whitespace errors.
What are considered whitespace errors is controlled by `core.whitespace`
configuration. By default, trailing whitespaces (including
- lines that solely consist of whitespaces) and a space character
+ lines that consist solely of whitespaces) and a space character
that is immediately followed by a tab character inside the
initial indent of the line are considered whitespace errors.
Exits with non-zero status if problems are found. Not compatible
with --exit-code.
--ws-error-highlight=<kind>::
- Highlight whitespace errors on lines specified by <kind>
- in the color specified by `color.diff.whitespace`. <kind>
- is a comma separated list of `old`, `new`, `context`. When
- this option is not given, only whitespace errors in `new`
- lines are highlighted. E.g. `--ws-error-highlight=new,old`
- highlights whitespace errors on both deleted and added lines.
- `all` can be used as a short-hand for `old,new,context`.
- The `diff.wsErrorHighlight` configuration variable can be
- used to specify the default behaviour.
+ Highlight whitespace errors in the `context`, `old` or `new`
+ lines of the diff. Multiple values are separated by comma,
+ `none` resets previous values, `default` reset the list to
+ `new` and `all` is a shorthand for `old,new,context`. When
+ this option is not given, and the configuration variable
+ `diff.wsErrorHighlight` is not set, only whitespace errors in
+ `new` lines are highlighted. The whitespace errors are colored
+ with `color.diff.whitespace`.
endif::git-format-patch[]
@@ -392,7 +489,7 @@ endif::git-log[]
the diff between the preimage and `/dev/null`. The resulting patch
is not meant to be applied with `patch` or `git apply`; this is
solely for people who want to just concentrate on reviewing the
- text after the change. In addition, the output obviously lack
+ text after the change. In addition, the output obviously lacks
enough information to apply such a patch in reverse, even manually,
hence the name of the option.
+
@@ -421,6 +518,12 @@ ifndef::git-format-patch[]
+
Also, these upper-case letters can be downcased to exclude. E.g.
`--diff-filter=ad` excludes added and deleted paths.
++
+Note that not all diffs can feature all types. For instance, diffs
+from the index to the working tree can never have Added entries
+(because the set of paths included in the diff is limited by what is in
+the index). Similarly, copied and renamed entries cannot appear if
+detection for those types is disabled.
-S<string>::
Look for differences that change the number of occurrences of
@@ -432,6 +535,8 @@ struct), and want to know the history of that block since it first
came into being: use the feature iteratively to feed the interesting
block in the preimage back into `-S`, and keep going until you get the
very first version of the block.
++
+Binary files are searched as well.
-G<regex>::
Look for differences whose patch text contains added/removed
@@ -451,9 +556,21 @@ While `git log -G"regexec\(regexp"` will show this commit, `git log
-S"regexec\(regexp" --pickaxe-regex` will not (because the number of
occurrences of that string did not change).
+
+Unless `--text` is supplied patches of binary files without a textconv
+filter will be ignored.
++
See the 'pickaxe' entry in linkgit:gitdiffcore[7] for more
information.
+--find-object=<object-id>::
+ Look for differences that change the number of occurrences of
+ the specified object. Similar to `-S`, just the argument is different
+ in that it doesn't search for a specific string but for a specific
+ object id.
++
+The object can be a blob or a submodule commit. It implies the `-t` option in
+`git-log` to also find trees.
+
--pickaxe-all::
When `-S` or `-G` finds a change, show all the changes in that
changeset, not just the files that contain the change
@@ -462,6 +579,7 @@ information.
--pickaxe-regex::
Treat the <string> given to `-S` as an extended POSIX regular
expression to match.
+
endif::git-format-patch[]
-O<orderfile>::
@@ -496,7 +614,7 @@ the normal order.
--
+
Patterns have the same syntax and semantics as patterns used for
-fnmantch(3) without the FNM_PATHNAME flag, except a pathname also
+fnmatch(3) without the FNM_PATHNAME flag, except a pathname also
matches a pattern if removing any number of the final pathname
components matches the pattern. For example, the pattern "`foo*bar`"
matches "`fooasdfbar`" and "`foo/bar/baz/asdf`" but not "`foobarx`".
@@ -519,6 +637,9 @@ endif::git-format-patch[]
--text::
Treat all files as text.
+--ignore-cr-at-eol::
+ Ignore carriage-return at the end of line when doing a comparison.
+
--ignore-space-at-eol::
Ignore changes in whitespace at EOL.
diff --git a/en/fetch-options.txt b/en/fetch-options.txt
index fb6bebbc618c3f71ab400ff4267264a0167a887a..fa0a3151b3f7e96ee61e65669e057e48ee053aae 100644
--- a/en/fetch-options.txt
+++ b/en/fetch-options.txt
@@ -42,6 +42,25 @@ the current repository has the same history as the source repository.
.git/shallow. This option updates .git/shallow and accept such
refs.
+--negotiation-tip=<commit|glob>::
+ By default, Git will report, to the server, commits reachable
+ from all local refs to find common commits in an attempt to
+ reduce the size of the to-be-received packfile. If specified,
+ Git will only report commits reachable from the given tips.
+ This is useful to speed up fetches when the user knows which
+ local ref is likely to have commits in common with the
+ upstream ref being fetched.
++
+This option may be specified more than once; if so, Git will report
+commits reachable from any of the given commits.
++
+The argument to this option may be a glob on ref names, a ref, or the (possibly
+abbreviated) SHA-1 of a commit. Specifying a glob is equivalent to specifying
+this option multiple times, one for each matching ref name.
++
+See also the `fetch.negotiationAlgorithm` configuration variable
+documented in linkgit:git-config[1].
+
ifndef::git-pull[]
--dry-run::
Show what would be done, without making any changes.
@@ -49,11 +68,16 @@ endif::git-pull[]
-f::
--force::
- When 'git fetch' is used with `<rbranch>:<lbranch>`
- refspec, it refuses to update the local branch
- `<lbranch>` unless the remote branch `<rbranch>` it
- fetches is a descendant of `<lbranch>`. This option
- overrides that check.
+ When 'git fetch' is used with `<src>:<dst>` refspec it may
+ refuse to update the local branch as discussed
+ifdef::git-pull[]
+ in the `<refspec>` part of the linkgit:git-fetch[1]
+ documentation.
+endif::git-pull[]
+ifndef::git-pull[]
+ in the `<refspec>` part below.
+endif::git-pull[]
+ This option overrides that check.
-k::
--keep::
@@ -73,7 +97,22 @@ ifndef::git-pull[]
are fetched due to an explicit refspec (either on the command
line or in the remote configuration, for example if the remote
was cloned with the --mirror option), then they are also
- subject to pruning.
+ subject to pruning. Supplying `--prune-tags` is a shorthand for
+ providing the tag refspec.
++
+See the PRUNING section below for more details.
+
+-P::
+--prune-tags::
+ Before fetching, remove any local tags that no longer exist on
+ the remote if `--prune` is enabled. This option should be used
+ more carefully, unlike `--prune` it will remove any local
+ references (local tags) that have been created. This option is
+ a shorthand for providing the explicit tag refspec along with
+ `--prune`, see the discussion about that in its documentation.
++
+See the PRUNING section below for more details.
+
endif::git-pull[]
ifndef::git-pull[]
@@ -173,6 +212,14 @@ endif::git-pull[]
is specified. This flag forces progress status even if the
standard error stream is not directed to a terminal.
+-o <option>::
+--server-option=<option>::
+ Transmit the given string to the server when communicating using
+ protocol version 2. The given string must not contain a NUL or LF
+ character.
+ When multiple `--server-option=<option>` are given, they are all
+ sent to the other side in the order listed on the command line.
+
-4::
--ipv4::
Use IPv4 addresses only, ignoring IPv6 addresses.
diff --git a/en/fmt-merge-msg-config.txt b/en/fmt-merge-msg-config.txt
deleted file mode 100644
index c73cfa90b70c59c14cd4984c950711bef5b3f6bf..0000000000000000000000000000000000000000
--- a/en/fmt-merge-msg-config.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-merge.branchdesc::
- In addition to branch names, populate the log message with
- the branch description text associated with them. Defaults
- to false.
-
-merge.log::
- In addition to branch names, populate the log message with at
- most the specified number of one-line descriptions from the
- actual commits that are being merged. Defaults to false, and
- true is a synonym for 20.
diff --git a/en/git-add.txt b/en/git-add.txt
index c2b5ce9d1943585487b1ec022c89d41fbceb4959..37bcab94d5e435849c22ddd0473be5cfb1c56140 100644
--- a/en/git-add.txt
+++ b/en/git-add.txt
@@ -10,7 +10,7 @@ SYNOPSIS
[verse]
'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p]
[--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]]
- [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing]
+ [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
[--chmod=(+|-)x] [--] [<pathspec>...]
DESCRIPTION
@@ -61,6 +61,9 @@ OPTIONS
the working tree). Note that older versions of Git used
to ignore removed files; use `--no-all` option if you want
to add modified or new files but ignore removed ones.
++
+For more details about the <pathspec> syntax, see the 'pathspec' entry
+in linkgit:gitglossary[7].
-n::
--dry-run::
@@ -165,6 +168,20 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files.
be ignored, no matter if they are already present in the work
tree or not.
+--no-warn-embedded-repo::
+ By default, `git add` will warn when adding an embedded
+ repository to the index without using `git submodule add` to
+ create an entry in `.gitmodules`. This option will suppress the
+ warning (e.g., if you are manually performing operations on
+ submodules).
+
+--renormalize::
+ Apply the "clean" process freshly to all tracked files to
+ forcibly add them again to the index. This is useful after
+ changing `core.autocrlf` configuration or the `text` attribute
+ in order to correct files added with wrong CRLF/LF line endings.
+ This option implies `-u`.
+
--chmod=(+|-)x::
Override the executable bit of the added files. The executable
bit is only changed in the index, the files on disk are left
@@ -176,7 +193,7 @@ for "git add --no-all <pathspec>...", i.e. ignored removed files.
for command-line options).
-Configuration
+CONFIGURATION
-------------
The optional configuration variable `core.excludesFile` indicates a path to a
@@ -209,7 +226,7 @@ Because this example lets the shell expand the asterisk (i.e. you are
listing the files explicitly), it does not consider
`subdir/git-foo.sh`.
-Interactive mode
+INTERACTIVE MODE
----------------
When the command enters the interactive mode, it shows the
output of the 'status' subcommand, and then goes into its
diff --git a/en/git-am.txt b/en/git-am.txt
index 12879e4029a7710e2d78bae476f7ad7d9b0fe830..6f6c34b0f4bc9ba18ec890dff1a6fe10af2fd68f 100644
--- a/en/git-am.txt
+++ b/en/git-am.txt
@@ -16,7 +16,7 @@ SYNOPSIS
[--exclude=<path>] [--include=<path>] [--reject] [-q | --quiet]
[--[no-]scissors] [-S[<keyid>]] [--patch-format=<format>]
[(<mbox> | <Maildir>)...]
-'git am' (--continue | --skip | --abort)
+'git am' (--continue | --skip | --abort | --quit | --show-current-patch)
DESCRIPTION
-----------
@@ -167,6 +167,14 @@ default. You can use `--no-utf8` to override this.
--abort::
Restore the original branch and abort the patching operation.
+--quit::
+ Abort the patching operation but keep HEAD and the index
+ untouched.
+
+--show-current-patch::
+ Show the patch being applied when "git am" is stopped because
+ of conflicts.
+
DISCUSSION
----------
diff --git a/en/git-annotate.txt b/en/git-annotate.txt
index 94be4b85e099f8b67901a737b8347ee02e6c6a6c..e44a831339d4a6d7f9ca3d9879dbb5a9b4ffac0a 100644
--- a/en/git-annotate.txt
+++ b/en/git-annotate.txt
@@ -8,7 +8,7 @@ git-annotate - Annotate file lines with commit information
SYNOPSIS
--------
[verse]
-'git annotate' [options] file [revision]
+'git annotate' [<options>] <file> [<revision>]
DESCRIPTION
-----------
@@ -23,7 +23,6 @@ familiar command name for people coming from other SCM systems.
OPTIONS
-------
include::blame-options.txt[]
-include::diff-heuristic-options.txt[]
SEE ALSO
--------
diff --git a/en/git-apply.txt b/en/git-apply.txt
index 631cbd840a08eb29add1e900ac9272992669a75c..b9aa39000fc8aa77d69751d9409a957139c2cff7 100644
--- a/en/git-apply.txt
+++ b/en/git-apply.txt
@@ -9,7 +9,7 @@ git-apply - Apply a patch to files and/or to the index
SYNOPSIS
--------
[verse]
-'git apply' [--stat] [--numstat] [--summary] [--check] [--index] [--3way]
+'git apply' [--stat] [--numstat] [--summary] [--check] [--index | --intent-to-add] [--3way]
[--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse]
[--allow-binary-replacement | --binary] [--reject] [-z]
[-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached]
@@ -66,7 +66,7 @@ OPTIONS
disables it is in effect), make sure the patch is
applicable to what the current index file records. If
the file to be patched in the working tree is not
- up-to-date, it is flagged as an error. This flag also
+ up to date, it is flagged as an error. This flag also
causes the index file to be updated.
--cached::
@@ -74,6 +74,14 @@ OPTIONS
cached data, apply the patch, and store the result in the index
without using the working tree. This implies `--index`.
+--intent-to-add::
+ When applying the patch only to the working tree, mark new
+ files to be added to the index later (see `--intent-to-add`
+ option in linkgit:git-add[1]). This option is ignored unless
+ running in a Git repository and `--index` is not specified.
+ Note that `--index` could be implied by other options such
+ as `--cached` or `--3way`.
+
-3::
--3way::
When the patch does not apply cleanly, fall back on 3-way merge if
@@ -113,8 +121,10 @@ explained for the configuration variable `core.quotePath` (see
linkgit:git-config[1]).
-p<n>::
- Remove <n> leading slashes from traditional diff paths. The
- default is 1.
+ Remove <n> leading path components (separated by slashes) from
+ traditional diff paths. E.g., with `-p2`, a patch against
+ `a/dir/file` will be applied directly to `file`. The default is
+ 1.
-C<n>::
Ensure at least <n> lines of surrounding context match before
@@ -240,7 +250,7 @@ When `git apply` is used as a "better GNU patch", the user can pass
the `--unsafe-paths` option to override this safety check. This option
has no effect when `--index` or `--cached` is in use.
-Configuration
+CONFIGURATION
-------------
apply.ignoreWhitespace::
@@ -251,7 +261,7 @@ apply.whitespace::
When no `--whitespace` flag is given from the command
line, this configuration item is used as the default.
-Submodules
+SUBMODULES
----------
If the patch contains any changes to submodules then 'git apply'
treats these changes as follows.
@@ -259,7 +269,7 @@ treats these changes as follows.
If `--index` is specified (explicitly or implicitly), then the submodule
commits must match the index exactly for the patch to apply. If any
of the submodules are checked-out, then these check-outs are completely
-ignored, i.e., they are not required to be up-to-date or clean and they
+ignored, i.e., they are not required to be up to date or clean and they
are not updated.
If `--index` is not specified, then the submodule commits in the patch
diff --git a/en/git-archimport.txt b/en/git-archimport.txt
index 163b9f6f4140d787e3edccd7c13deadff789c3f3..a595a0ffeee56d8426907c9297078fac6977e5a3 100644
--- a/en/git-archimport.txt
+++ b/en/git-archimport.txt
@@ -3,7 +3,7 @@ git-archimport(1)
NAME
----
-git-archimport - Import an Arch repository into Git
+git-archimport - Import a GNU Arch repository into Git
SYNOPSIS
@@ -14,7 +14,8 @@ SYNOPSIS
DESCRIPTION
-----------
-Imports a project from one or more Arch repositories. It will follow branches
+Imports a project from one or more GNU Arch repositories.
+It will follow branches
and repositories within the namespaces defined by the <archive/branch>
parameters supplied. If it cannot find the remote branch a merge comes from
it will just import it as a regular commit. If it can find it, it will mark it
@@ -96,7 +97,7 @@ OPTIONS
pruned.
-a::
- Attempt to auto-register archives at http://mirrors.sourcecontrol.net
+ Attempt to auto-register archives at `http://mirrors.sourcecontrol.net`
This is particularly useful with the -D option.
-t <tmpdir>::
diff --git a/en/git-bisect.txt b/en/git-bisect.txt
index bdd915a66b481dccf9ae6d601b5497ceb6b3b3d7..4b45d837a7e7c590fe3aa5f575009c43342b833c 100644
--- a/en/git-bisect.txt
+++ b/en/git-bisect.txt
@@ -23,7 +23,7 @@ on the subcommand:
git bisect terms [--term-good | --term-bad]
git bisect skip [(<rev>|<range>)...]
git bisect reset [<commit>]
- git bisect visualize
+ git bisect (visualize|view)
git bisect replay <logfile>
git bisect log
git bisect run <cmd>...
@@ -137,7 +137,7 @@ respectively, in place of "good" and "bad". (But note that you cannot
mix "good" and "bad" with "old" and "new" in a single session.)
In this more general usage, you provide `git bisect` with a "new"
-commit has some property and an "old" commit that doesn't have that
+commit that has some property and an "old" commit that doesn't have that
property. Each time `git bisect` checks out a commit, you test if that
commit has the property. If it does, mark the commit as "new";
otherwise, mark it as "old". When the bisection is done, `git bisect`
@@ -165,8 +165,8 @@ To get a reminder of the currently used terms, use
git bisect terms
------------------------------------------------
-You can get just the old (respectively new) term with `git bisect term
---term-old` or `git bisect term --term-good`.
+You can get just the old (respectively new) term with `git bisect terms
+--term-old` or `git bisect terms --term-good`.
If you would like to use your own terms instead of "bad"/"good" or
"new"/"old", you can choose any names you like (except existing bisect
@@ -193,24 +193,23 @@ git bisect start --term-new fixed --term-old broken
Then, use `git bisect <term-old>` and `git bisect <term-new>` instead
of `git bisect good` and `git bisect bad` to mark commits.
-Bisect visualize
-~~~~~~~~~~~~~~~~
+Bisect visualize/view
+~~~~~~~~~~~~~~~~~~~~~
To see the currently remaining suspects in 'gitk', issue the following
-command during the bisection process:
+command during the bisection process (the subcommand `view` can be used
+as an alternative to `visualize`):
------------
$ git bisect visualize
------------
-`view` may also be used as a synonym for `visualize`.
-
If the `DISPLAY` environment variable is not set, 'git log' is used
instead. You can also give command-line options such as `-p` and
`--stat`.
------------
-$ git bisect view --stat
+$ git bisect visualize --stat
------------
Bisect log and bisect replay
diff --git a/en/git-blame.txt b/en/git-blame.txt
index fdc3aea30a4cdb480d469455a66e51a76366be93..16323eb80e3108794067c4dbfcbfe25e46938498 100644
--- a/en/git-blame.txt
+++ b/en/git-blame.txt
@@ -89,8 +89,6 @@ include::blame-options.txt[]
abbreviated object name, use <n>+1 digits. Note that 1 column
is used for a caret to mark the boundary commit.
-include::diff-heuristic-options.txt[]
-
THE PORCELAIN FORMAT
--------------------
diff --git a/en/git-branch.txt b/en/git-branch.txt
index 092f1bcf9f89f124a2d3c80eadeab5b4a63db941..3bd83a7cbdd9d62c9b10057bd4bf3f03d57b1085 100644
--- a/en/git-branch.txt
+++ b/en/git-branch.txt
@@ -10,13 +10,15 @@ SYNOPSIS
[verse]
'git branch' [--color[=<when>] | --no-color] [-r | -a]
[--list] [-v [--abbrev=<length> | --no-abbrev]]
- [--column[=<options>] | --no-column]
- [(--merged | --no-merged | --contains) [<commit>]] [--sort=<key>]
+ [--column[=<options>] | --no-column] [--sort=<key>]
+ [(--merged | --no-merged) [<commit>]]
+ [--contains [<commit]] [--no-contains [<commit>]]
[--points-at <object>] [--format=<format>] [<pattern>...]
-'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
+'git branch' [--track | --no-track] [-f] <branchname> [<start-point>]
'git branch' (--set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
'git branch' --unset-upstream [<branchname>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
+'git branch' (-c | -C) [<oldbranch>] <newbranch>
'git branch' (-d | -D) [-r] <branchname>...
'git branch' --edit-description [<branchname>]
@@ -35,11 +37,12 @@ as branch creation.
With `--contains`, shows only the branches that contain the named commit
(in other words, the branches whose tip commits are descendants of the
-named commit). With `--merged`, only branches merged into the named
-commit (i.e. the branches whose tip commits are reachable from the named
-commit) will be listed. With `--no-merged` only branches not merged into
-the named commit will be listed. If the <commit> argument is missing it
-defaults to `HEAD` (i.e. the tip of the current branch).
+named commit), `--no-contains` inverts it. With `--merged`, only branches
+merged into the named commit (i.e. the branches whose tip commits are
+reachable from the named commit) will be listed. With `--no-merged` only
+branches not merged into the named commit will be listed. If the <commit>
+argument is missing it defaults to `HEAD` (i.e. the tip of the current
+branch).
The command's second form creates a new branch head named <branchname>
which points to the current `HEAD`, or <start-point> if given.
@@ -62,6 +65,10 @@ If <oldbranch> had a corresponding reflog, it is renamed to match
renaming. If <newbranch> exists, -M must be used to force the rename
to happen.
+The `-c` and `-C` options have the exact same semantics as `-m` and
+`-M`, except instead of the branch being renamed it along with its
+config and reflog will be copied to a new name.
+
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a reflog then the reflog will also be deleted.
@@ -79,30 +86,29 @@ OPTIONS
--delete::
Delete a branch. The branch must be fully merged in its
upstream branch, or in `HEAD` if no upstream was set with
- `--track` or `--set-upstream`.
+ `--track` or `--set-upstream-to`.
-D::
Shortcut for `--delete --force`.
--l::
--create-reflog::
Create the branch's reflog. This activates recording of
all changes made to the branch ref, enabling use of date
based sha1 expressions such as "<branchname>@\{yesterday}".
Note that in non-bare repositories, reflogs are usually
- enabled by default by the `core.logallrefupdates` config option.
+ enabled by default by the `core.logAllRefUpdates` config option.
The negated form `--no-create-reflog` only overrides an earlier
`--create-reflog`, but currently does not negate the setting of
- `core.logallrefupdates`.
+ `core.logAllRefUpdates`.
-f::
--force::
- Reset <branchname> to <startpoint> if <branchname> exists
- already. Without `-f` 'git branch' refuses to change an existing branch.
+ Reset <branchname> to <startpoint>, even if <branchname> exists
+ already. Without `-f`, 'git branch' refuses to change an existing branch.
In combination with `-d` (or `--delete`), allow deleting the
branch irrespective of its merged status. In combination with
`-m` (or `--move`), allow renaming the branch even if the new
- branch name already exists.
+ branch name already exists, the same applies for `-c` (or `--copy`).
-m::
--move::
@@ -111,6 +117,13 @@ OPTIONS
-M::
Shortcut for `--move --force`.
+-c::
+--copy::
+ Copy a branch and the corresponding reflog.
+
+-C::
+ Shortcut for `--copy --force`.
+
--color[=<when>]::
Color branches to highlight current, local, and
remote-tracking branches.
@@ -141,9 +154,11 @@ This option is only applicable in non-verbose mode.
--all::
List both remote-tracking branches and local branches.
+-l::
--list::
- Activate the list mode. `git branch <pattern>` would try to create a branch,
- use `git branch --list <pattern>` to list matching branches.
+ List branches. With optional `<pattern>...`, e.g. `git
+ branch --list 'maint-*'`, list only the branches that match
+ the pattern(s).
-v::
-vv::
@@ -188,10 +203,8 @@ start-point is either a local or remote-tracking branch.
branch.autoSetupMerge configuration variable is true.
--set-upstream::
- If specified branch does not exist yet or if `--force` has been
- given, acts exactly like `--track`. Otherwise sets up configuration
- like `--track` would when creating the branch, except that where
- branch points to is not changed.
+ As this option had confusing syntax, it is no longer supported.
+ Please use `--track` or `--set-upstream-to` instead.
-u <upstream>::
--set-upstream-to=<upstream>::
@@ -213,13 +226,19 @@ start-point is either a local or remote-tracking branch.
Only list branches which contain the specified commit (HEAD
if not specified). Implies `--list`.
+--no-contains [<commit>]::
+ Only list branches which don't contain the specified commit
+ (HEAD if not specified). Implies `--list`.
+
--merged [<commit>]::
Only list branches whose tips are reachable from the
- specified commit (HEAD if not specified). Implies `--list`.
+ specified commit (HEAD if not specified). Implies `--list`,
+ incompatible with `--no-merged`.
--no-merged [<commit>]::
Only list branches whose tips are not reachable from the
- specified commit (HEAD if not specified). Implies `--list`.
+ specified commit (HEAD if not specified). Implies `--list`,
+ incompatible with `--merged`.
<branchname>::
The name of the branch to create or delete.
@@ -244,21 +263,28 @@ start-point is either a local or remote-tracking branch.
order of the value. You may use the --sort=<key> option
multiple times, in which case the last key becomes the primary
key. The keys supported are the same as those in `git
- for-each-ref`. Sort order defaults to sorting based on the
+ for-each-ref`. Sort order defaults to the value configured for the
+ `branch.sort` variable if exists, or to sorting based on the
full refname (including `refs/...` prefix). This lists
detached HEAD (if present) first, then local branches and
- finally remote-tracking branches.
+ finally remote-tracking branches. See linkgit:git-config[1].
--points-at <object>::
Only list branches of the given object.
--format <format>::
- A string that interpolates `%(fieldname)` from the object
- pointed at by a ref being shown. The format is the same as
+ A string that interpolates `%(fieldname)` from a branch ref being shown
+ and the object it points at. The format is the same as
that of linkgit:git-for-each-ref[1].
-Examples
+CONFIGURATION
+-------------
+`pager.branch` is only respected when listing branches, i.e., when
+`--list` is used or implied. The default is to use a pager.
+See linkgit:git-config[1].
+
+EXAMPLES
--------
Start development from a known tag::
@@ -271,7 +297,7 @@ $ git checkout my2.6.14
------------
+
<1> This step and the next one could be combined into a single step with
-"checkout -b my2.6.14 v2.6.14".
+ "checkout -b my2.6.14 v2.6.14".
Delete an unneeded branch::
+
@@ -283,26 +309,29 @@ $ git branch -D test <2>
------------
+
<1> Delete the remote-tracking branches "todo", "html" and "man". The next
-'fetch' or 'pull' will create them again unless you configure them not to.
-See linkgit:git-fetch[1].
+ 'fetch' or 'pull' will create them again unless you configure them not to.
+ See linkgit:git-fetch[1].
<2> Delete the "test" branch even if the "master" branch (or whichever branch
-is currently checked out) does not have all commits from the test branch.
+ is currently checked out) does not have all commits from the test branch.
-Notes
+NOTES
-----
If you are creating a branch that you want to checkout immediately, it is
easier to use the git checkout command with its `-b` option to create
a branch and check it out with a single command.
-The options `--contains`, `--merged` and `--no-merged` serve three related
-but different purposes:
+The options `--contains`, `--no-contains`, `--merged` and `--no-merged`
+serve four related but different purposes:
- `--contains <commit>` is used to find all branches which will need
special attention if <commit> were to be rebased or amended, since those
branches contain the specified <commit>.
+- `--no-contains <commit>` is the inverse of that, i.e. branches that don't
+ contain the specified <commit>.
+
- `--merged` is used to find all branches which can be safely deleted,
since those branches are fully contained by HEAD.
diff --git a/en/git-bundle.txt b/en/git-bundle.txt
index 3a8120c3b3795784cb05211bcde959a224f0a867..7d6c9dcd177b6a1fa4a6184b230480aa08e07120 100644
--- a/en/git-bundle.txt
+++ b/en/git-bundle.txt
@@ -92,8 +92,8 @@ It is okay to err on the side of caution, causing the bundle file
to contain objects already in the destination, as these are ignored
when unpacking at the destination.
-EXAMPLE
--------
+EXAMPLES
+--------
Assume you want to transfer the history from a repository R1 on machine A
to another repository R2 on machine B.
diff --git a/en/git-cat-file.txt b/en/git-cat-file.txt
index 204541c690ce24bdf5b6e20baa0ddca928920f71..8eca671b8278cfe02692605b80a9121bc5717567 100644
--- a/en/git-cat-file.txt
+++ b/en/git-cat-file.txt
@@ -23,8 +23,8 @@ In the second form, a list of objects (separated by linefeeds) is provided on
stdin, and the SHA-1, type, and size of each object is printed on stdout. The
output format can be overridden using the optional `<format>` argument. If
either `--textconv` or `--filters` was specified, the input is expected to
-list the object names followed by the path name, separated by a single white
-space, so that the appropriate drivers can be determined.
+list the object names followed by the path name, separated by a single
+whitespace, so that the appropriate drivers can be determined.
OPTIONS
-------
@@ -42,8 +42,9 @@ OPTIONS
<object>.
-e::
- Suppress all output; instead exit with zero status if <object>
- exists and is a valid object.
+ Exit with zero status if <object> exists and is a valid
+ object. If <object> is of an invalid format exit with non-zero and
+ emits an error on stderr.
-p::
Pretty-print the contents of <object> based on its type.
@@ -78,7 +79,7 @@ OPTIONS
Print object information and contents for each object provided
on stdin. May not be combined with any other options or arguments
except `--textconv` or `--filters`, in which case the input lines
- also need to specify the path, separated by white space. See the
+ also need to specify the path, separated by whitespace. See the
section `BATCH OUTPUT` below for details.
--batch-check::
@@ -86,7 +87,7 @@ OPTIONS
Print object information for each object provided on stdin. May
not be combined with any other options or arguments except
`--textconv` or `--filters`, in which case the input lines also
- need to specify the path, separated by white space. See the
+ need to specify the path, separated by whitespace. See the
section `BATCH OUTPUT` below for details.
--batch-all-objects::
@@ -103,6 +104,16 @@ OPTIONS
buffering; this is much more efficient when invoking
`--batch-check` on a large number of objects.
+--unordered::
+ When `--batch-all-objects` is in use, visit objects in an
+ order which may be more efficient for accessing the object
+ contents than hash order. The exact details of the order are
+ unspecified, but if you do not require a specific order, this
+ should generally result in faster output, especially with
+ `--batch`. Note that `cat-file` will still show each object
+ only once, even if it is stored multiple times in the
+ repository.
+
--allow-unknown-type::
Allow -s or -t to query broken/corrupt objects of unknown type.
@@ -168,7 +179,7 @@ If `-t` is specified, one of the <type>.
If `-s` is specified, the size of the <object> in bytes.
-If `-e` is specified, no output.
+If `-e` is specified, no output, unless the <object> is malformed.
If `-p` is specified, the contents of <object> are pretty-printed.
@@ -192,7 +203,7 @@ newline. The available atoms are:
The 40-hex object name of the object.
`objecttype`::
- The type of of the object (the same as `cat-file -t` reports).
+ The type of the object (the same as `cat-file -t` reports).
`objectsize`::
The size, in bytes, of the object (the same as `cat-file -s`
@@ -241,6 +252,12 @@ the repository, then `cat-file` will ignore any custom format and print:
<object> SP missing LF
------------
+If a name is specified that might refer to more than one object (an ambiguous short sha), then `cat-file` will ignore any custom format and print:
+
+------------
+<object> SP ambiguous LF
+------------
+
If --follow-symlinks is used, and a symlink in the repository points
outside the repository, then `cat-file` will ignore any custom format
and print:
diff --git a/en/git-check-attr.txt b/en/git-check-attr.txt
index aa3b2bf2fcf764ca22f44bcfc081afd4e09328bb..3c0578217ba7f92f823e545021c5c06c31566f0d 100644
--- a/en/git-check-attr.txt
+++ b/en/git-check-attr.txt
@@ -9,8 +9,8 @@ git-check-attr - Display gitattributes information
SYNOPSIS
--------
[verse]
-'git check-attr' [-a | --all | attr...] [--] pathname...
-'git check-attr' --stdin [-z] [-a | --all | attr...]
+'git check-attr' [-a | --all | <attr>...] [--] <pathname>...
+'git check-attr' --stdin [-z] [-a | --all | <attr>...]
DESCRIPTION
-----------
diff --git a/en/git-check-ignore.txt b/en/git-check-ignore.txt
index 611754f10bb86d62edcb3265cc29ccdc97c259ae..8b42cb3fb20a78cde2eb4c6a7546a334cc71ec4b 100644
--- a/en/git-check-ignore.txt
+++ b/en/git-check-ignore.txt
@@ -9,8 +9,8 @@ git-check-ignore - Debug gitignore / exclude files
SYNOPSIS
--------
[verse]
-'git check-ignore' [options] pathname...
-'git check-ignore' [options] --stdin
+'git check-ignore' [<options>] <pathname>...
+'git check-ignore' [<options>] --stdin
DESCRIPTION
-----------
diff --git a/en/git-check-mailmap.txt b/en/git-check-mailmap.txt
index 39028ee1a34e63325d68bb900854b4fe8aa66457..aa2055dbebcd4237e7557db7926700c933f8ac94 100644
--- a/en/git-check-mailmap.txt
+++ b/en/git-check-mailmap.txt
@@ -9,7 +9,7 @@ git-check-mailmap - Show canonical names and email addresses of contacts
SYNOPSIS
--------
[verse]
-'git check-mailmap' [options] <contact>...
+'git check-mailmap' [<options>] <contact>...
DESCRIPTION
diff --git a/en/git-check-ref-format.txt b/en/git-check-ref-format.txt
index 92777cef25e1145fc2a060d572255be564dec491..d9de9925856d79784441bc6d66623f533b844396 100644
--- a/en/git-check-ref-format.txt
+++ b/en/git-check-ref-format.txt
@@ -77,11 +77,23 @@ reference name expressions (see linkgit:gitrevisions[7]):
. at-open-brace `@{` is used as a notation to access a reflog entry.
-With the `--branch` option, it expands the ``previous branch syntax''
-`@{-n}`. For example, `@{-1}` is a way to refer the last branch you
-were on. This option should be used by porcelains to accept this
-syntax anywhere a branch name is expected, so they can act as if you
-typed the branch name.
+With the `--branch` option, the command takes a name and checks if
+it can be used as a valid branch name (e.g. when creating a new
+branch). But be cautious when using the
+previous checkout syntax that may refer to a detached HEAD state.
+The rule `git check-ref-format --branch $name` implements
+may be stricter than what `git check-ref-format refs/heads/$name`
+says (e.g. a dash may appear at the beginning of a ref component,
+but it is explicitly forbidden at the beginning of a branch name).
+When run with `--branch` option in a repository, the input is first
+expanded for the ``previous checkout syntax''
+`@{-n}`. For example, `@{-1}` is a way to refer the last thing that
+was checked out using "git checkout" operation. This option should be
+used by porcelains to accept this syntax anywhere a branch name is
+expected, so they can act as if you typed the branch name. As an
+exception note that, the ``previous checkout operation'' might result
+in a commit object name when the N-th last thing checked out was not
+a branch.
OPTIONS
-------
@@ -109,7 +121,7 @@ OPTIONS
EXAMPLES
--------
-* Print the name of the previous branch:
+* Print the name of the previous thing checked out:
+
------------
$ git check-ref-format --branch @{-1}
diff --git a/en/git-checkout.txt b/en/git-checkout.txt
index 8e2c0662ddd72c1bc0765aadbbafd22b62b5adf6..9a396498d106e1f3ff581d465c072d90686f8c21 100644
--- a/en/git-checkout.txt
+++ b/en/git-checkout.txt
@@ -13,7 +13,8 @@ SYNOPSIS
'git checkout' [-q] [-f] [-m] [--detach] <commit>
'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
-'git checkout' [-p|--patch] [<tree-ish>] [--] [<paths>...]
+'git checkout' [<tree-ish>] [--] <pathspec>...
+'git checkout' (-p|--patch) [<tree-ish>] [--] [<paths>...]
DESCRIPTION
-----------
@@ -37,8 +38,17 @@ equivalent to
$ git checkout -b <branch> --track <remote>/<branch>
------------
+
+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
+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
+'origin' remote. See also `checkout.defaultRemote` in
+linkgit:git-config[1].
++
You could omit <branch>, in which case the command degenerates to
-"check out the current branch", which is a glorified no-op with a
+"check out the current branch", which is a glorified no-op with
rather expensive side-effects to show only the tracking information,
if exists, for the current branch.
@@ -78,20 +88,13 @@ be used to detach HEAD at the tip of the branch (`git checkout
+
Omitting <branch> detaches HEAD at the tip of the current branch.
-'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
+'git checkout' [<tree-ish>] [--] <pathspec>...::
- When <paths> or `--patch` are given, 'git checkout' does *not*
- switch branches. It updates the named paths in the working tree
- from the index file or from a named <tree-ish> (most often a
- commit). In this case, the `-b` and `--track` options are
- meaningless and giving either of them results in an error. The
- <tree-ish> argument can be used to specify a specific tree-ish
- (i.e. commit, tag or tree) to update the index for the given
- paths before updating the working tree.
-+
-'git checkout' with <paths> or `--patch` is used to restore modified or
-deleted paths to their original contents from the index or replace paths
-with the contents from a named <tree-ish> (most often a commit-ish).
+ Overwrite paths in the working tree by replacing with the
+ contents in the index or in the <tree-ish> (most often a
+ commit). When a <tree-ish> is given, the paths that
+ match the <pathspec> are updated both in the index and in
+ the working tree.
+
The index may contain unmerged entries because of a previous failed merge.
By default, if you try to check out such an entry from the index, the
@@ -101,6 +104,14 @@ specific side of the merge can be checked out of the index by
using `--ours` or `--theirs`. With `-m`, changes made to the working tree
file can be discarded to re-create the original conflicted merge result.
+'git checkout' (-p|--patch) [<tree-ish>] [--] [<pathspec>...]::
+ This is similar to the "check out paths to the working tree
+ from either the index or from a tree-ish" mode described
+ above, but lets you use the interactive interface to show
+ the "diff" output and choose which hunks to use in the
+ result. See below for the description of `--patch` option.
+
+
OPTIONS
-------
-q::
@@ -256,6 +267,19 @@ section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
out anyway. In other words, the ref can be held by more than one
worktree.
+--[no-]recurse-submodules::
+ Using --recurse-submodules will update the content of all initialized
+ submodules according to the commit recorded in the superproject. If
+ local modifications in a submodule would be overwritten the checkout
+ will fail unless `-f` is used. If nothing (or --no-recurse-submodules)
+ is used, the work trees of submodules will not be updated.
+ Just like linkgit:git-submodule[1], this will detach the
+ submodules HEAD.
+
+--no-guess::
+ Do not attempt to create a branch if a remote tracking branch
+ of the same name exists.
+
<branch>::
Branch to checkout; if it refers to a branch (i.e., a name that,
when prepended with "refs/heads/", is a valid ref), then that
@@ -263,11 +287,11 @@ section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
commit, your HEAD becomes "detached" and you are no longer on
any branch (see below for details).
+
-As a special case, the `"@{-N}"` syntax for the N-th last branch/commit
-checks out branches (instead of detaching). You may also specify
-`-` which is synonymous with `"@{-1}"`.
+You can use the `"@{-N}"` syntax to refer to the N-th last
+branch/commit checked out using "git checkout" operation. You may
+also specify `-` which is synonymous to `"@{-1}`.
+
-As a further special case, you may use `"A...B"` as a shortcut for the
+As a special case, you may use `"A...B"` as a shortcut for the
merge base of `A` and `B` if there is exactly one merge base. You can
leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
@@ -291,9 +315,9 @@ branch refers to a specific commit. Let's look at a repo with three
commits, one of them tagged, and with branch 'master' checked out:
------------
- HEAD (refers to branch 'master')
- |
- v
+ HEAD (refers to branch 'master')
+ |
+ v
a---b---c branch 'master' (refers to commit 'c')
^
|
@@ -309,9 +333,9 @@ to commit 'd':
------------
$ edit; git add; git commit
- HEAD (refers to branch 'master')
- |
- v
+ HEAD (refers to branch 'master')
+ |
+ v
a---b---c---d branch 'master' (refers to commit 'd')
^
|
@@ -378,7 +402,7 @@ at what happens when we then checkout master:
------------
$ git checkout master
- HEAD (refers to branch 'master')
+ HEAD (refers to branch 'master')
e---f |
/ v
a---b---c---d branch 'master' (refers to commit 'd')
@@ -400,14 +424,14 @@ $ git tag foo <3>
------------
<1> creates a new branch 'foo', which refers to commit 'f', and then
-updates HEAD to refer to branch 'foo'. In other words, we'll no longer
-be in detached HEAD state after this command.
+ updates HEAD to refer to branch 'foo'. In other words, we'll no longer
+ be in detached HEAD state after this command.
<2> similarly creates a new branch 'foo', which refers to commit 'f',
-but leaves HEAD detached.
+ but leaves HEAD detached.
<3> creates a new tag 'foo', which refers to commit 'f',
-leaving HEAD detached.
+ leaving HEAD detached.
If we have moved away from commit 'f', then we must first recover its object
name (typically by using git reflog), and then we can create a reference to
@@ -435,8 +459,8 @@ EXAMPLES
--------
. The following sequence checks out the `master` branch, reverts
-the `Makefile` to two revisions back, deletes hello.c by
-mistake, and gets it back from the index.
+ the `Makefile` to two revisions back, deletes hello.c by
+ mistake, and gets it back from the index.
+
------------
$ git checkout master <1>
@@ -470,7 +494,7 @@ $ git checkout -- hello.c
------------
. After working in the wrong branch, switching to the correct
-branch would be done using:
+ branch would be done using:
+
------------
$ git checkout mytopic
@@ -498,7 +522,7 @@ registered in your index file, so `git diff` would show you what
changes you made since the tip of the new branch.
. When a merge conflict happens during switching branches with
-the `-m` option, you would see something like this:
+ the `-m` option, you would see something like this:
+
------------
$ git checkout -m mytopic
diff --git a/en/git-cherry-pick.txt b/en/git-cherry-pick.txt
index d35d771fc8172e12958b4a9521c51a5f65cddebe..b8cfeec67e5fbdcfe1705a3b249f97b284932e79 100644
--- a/en/git-cherry-pick.txt
+++ b/en/git-cherry-pick.txt
@@ -213,16 +213,16 @@ $ git reset --merge ORIG_HEAD <3>
$ git cherry-pick -Xpatience topic^ <4>
------------
<1> apply the change that would be shown by `git show topic^`.
-In this example, the patch does not apply cleanly, so
-information about the conflict is written to the index and
-working tree and no new commit results.
+ In this example, the patch does not apply cleanly, so
+ information about the conflict is written to the index and
+ working tree and no new commit results.
<2> summarize changes to be reconciled
<3> cancel the cherry-pick. In other words, return to the
-pre-cherry-pick state, preserving any local modifications you had in
-the working tree.
+ pre-cherry-pick state, preserving any local modifications
+ you had in the working tree.
<4> try to apply the change introduced by `topic^` again,
-spending extra time to avoid mistakes based on incorrectly matching
-context lines.
+ spending extra time to avoid mistakes based on incorrectly
+ matching context lines.
SEE ALSO
--------
diff --git a/en/git-clone.txt b/en/git-clone.txt
index 35cc34b2fb9a0e696eb86e208416fa93aae3c0c5..2fd12524f95afef9c688d3402cd2a8b6d2d98c2e 100644
--- a/en/git-clone.txt
+++ b/en/git-clone.txt
@@ -13,8 +13,8 @@ SYNOPSIS
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
[-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
[--dissociate] [--separate-git-dir <git dir>]
- [--depth <depth>] [--[no-]single-branch]
- [--recursive | --recurse-submodules] [--[no-]shallow-submodules]
+ [--depth <depth>] [--[no-]single-branch] [--no-tags]
+ [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
[--jobs <n>] [--] <repository> [<directory>]
DESCRIPTION
@@ -189,6 +189,12 @@ objects from the source repository into a pack in the cloned repository.
values are given for the same key, each value will be written to
the config file. This makes it safe, for example, to add
additional fetch refspecs to the origin remote.
++
+Due to limitations of the current implementation, some configuration
+variables do not take effect until after the initial fetch and checkout.
+Configuration variables known to not take effect are:
+`remote.<name>.mirror` and `remote.<name>.tagOpt`. Use the
+corresponding `--mirror` and `--no-tags` options instead.
--depth <depth>::
Create a 'shallow' clone with a history truncated to the
@@ -215,14 +221,33 @@ objects from the source repository into a pack in the cloned repository.
branch when `--single-branch` clone was made, no remote-tracking
branch is created.
---recursive::
---recurse-submodules::
- After the clone is created, initialize all submodules within,
- using their default settings. This is equivalent to running
- `git submodule update --init --recursive` immediately after
- the clone is finished. This option is ignored if the cloned
- repository does not have a worktree/checkout (i.e. if any of
- `--no-checkout`/`-n`, `--bare`, or `--mirror` is given)
+--no-tags::
+ Don't clone any tags, and set
+ `remote.<remote>.tagOpt=--no-tags` in the config, ensuring
+ that future `git pull` and `git fetch` operations won't follow
+ any tags. Subsequent explicit tag fetches will still work,
+ (see linkgit:git-fetch[1]).
++
+Can be used in conjunction with `--single-branch` to clone and
+maintain a branch with no references other than a single cloned
+branch. This is useful e.g. to maintain minimal clones of the default
+branch of some repository for search indexing.
+
+--recurse-submodules[=<pathspec]::
+ After the clone is created, initialize and clone submodules
+ within based on the provided pathspec. If no pathspec is
+ provided, all submodules are initialized and cloned.
+ This option can be given multiple times for pathspecs consisting
+ of multiple entries. The resulting clone has `submodule.active` set to
+ the provided pathspec, or "." (meaning all submodules) if no
+ pathspec is provided.
++
+Submodules are initialized and cloned using their default settings. This is
+equivalent to running
+`git submodule update --init --recursive <pathspec>` immediately after
+the clone is finished. This option is ignored if the cloned repository does
+not have a worktree/checkout (i.e. if any of `--no-checkout`/`-n`, `--bare`,
+or `--mirror` is given)
--[no-]shallow-submodules::
All submodules which are cloned will be shallow with a depth of 1.
@@ -241,7 +266,7 @@ objects from the source repository into a pack in the cloned repository.
<repository>::
The (possibly remote) repository to clone from. See the
- <<URLS,URLS>> section below for more information on specifying
+ <<URLS,GIT URLS>> section below for more information on specifying
repositories.
<directory>::
@@ -254,7 +279,7 @@ objects from the source repository into a pack in the cloned repository.
:git-clone: 1
include::urls.txt[]
-Examples
+EXAMPLES
--------
* Clone from upstream:
diff --git a/en/git-column.txt b/en/git-column.txt
index 03d18465d4f2cc8327362917d1c808e523333d11..f58e9c43e60cec3b56fb84f54859f3d01d1a963a 100644
--- a/en/git-column.txt
+++ b/en/git-column.txt
@@ -13,7 +13,10 @@ SYNOPSIS
DESCRIPTION
-----------
-This command formats its input into multiple columns.
+This command formats the lines of its standard input into a table with
+multiple columns. Each input line occupies one cell of the table. It
+is used internally by other git commands to format output into
+columns.
OPTIONS
-------
@@ -23,7 +26,7 @@ OPTIONS
--mode=<mode>::
Specify layout mode. See configuration variable column.ui for option
- syntax.
+ syntax in linkgit:git-config[1].
--raw-mode=<n>::
Same as --mode but take mode encoded as a number. This is mainly used
@@ -43,6 +46,34 @@ OPTIONS
--padding=<N>::
The number of spaces between columns. One space by default.
+EXAMPLES
+--------
+
+Format data by columns:
+------------
+$ seq 1 24 | git column --mode=column --padding=5
+1 4 7 10 13 16 19 22
+2 5 8 11 14 17 20 23
+3 6 9 12 15 18 21 24
+------------
+
+Format data by rows:
+------------
+$ seq 1 21 | git column --mode=row --padding=5
+1 2 3 4 5 6 7
+8 9 10 11 12 13 14
+15 16 17 18 19 20 21
+------------
+
+List some tags in a table with unequal column widths:
+------------
+$ git tag --list 'v2.4.*' --column=row,dense
+v2.4.0 v2.4.0-rc0 v2.4.0-rc1 v2.4.0-rc2 v2.4.0-rc3
+v2.4.1 v2.4.10 v2.4.11 v2.4.12 v2.4.2
+v2.4.3 v2.4.4 v2.4.5 v2.4.6 v2.4.7
+v2.4.8 v2.4.9
+------------
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/en/git-commit.txt b/en/git-commit.txt
index ed0f5b94b3f200676aedb312391a2dd8fde7325d..a85c2c2a4c8127eb41a68b2f103281e3682e1554 100644
--- a/en/git-commit.txt
+++ b/en/git-commit.txt
@@ -17,16 +17,20 @@ SYNOPSIS
DESCRIPTION
-----------
-Stores the current contents of the index in a new commit along
-with a log message from the user describing the changes.
+Create a new commit containing the current contents of the index and
+the given log message describing the changes. The new commit is a
+direct child of HEAD, usually the tip of the current branch, and the
+branch is updated to point to it (unless no branch is associated with
+the working tree, in which case HEAD is "detached" as described in
+linkgit:git-checkout[1]).
-The content to be added can be specified in several ways:
+The content to be committed can be specified in several ways:
-1. by using 'git add' to incrementally "add" changes to the
- index before using the 'commit' command (Note: even modified
- files must be "added");
+1. by using linkgit:git-add[1] to incrementally "add" changes to the
+ index before using the 'commit' command (Note: even modified files
+ must be "added");
-2. by using 'git rm' to remove files from the working tree
+2. by using linkgit:git-rm[1] to remove files from the working tree
and the index, again before using the 'commit' command;
3. by listing files as arguments to the 'commit' command
@@ -95,7 +99,7 @@ OPTIONS
--reset-author::
When used with -C/-c/--amend options, or when committing after a
- a conflicting cherry-pick, declare that the authorship of the
+ conflicting cherry-pick, declare that the authorship of the
resulting commit now belongs to the committer. This also renews
the author timestamp.
@@ -112,7 +116,7 @@ OPTIONS
`--dry-run`.
--long::
- When doing a dry-run, give the output in a the long-format.
+ When doing a dry-run, give the output in the long-format.
Implies `--dry-run`.
-z::
@@ -144,6 +148,8 @@ OPTIONS
Use the given <msg> as the commit message.
If multiple `-m` options are given, their values are
concatenated as separate paragraphs.
++
+The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
-t <file>::
--template=<file>::
@@ -196,11 +202,12 @@ whitespace::
verbatim::
Do not change the message at all.
scissors::
- Same as `whitespace`, except that everything from (and
- including) the line
- "`# ------------------------ >8 ------------------------`"
- is truncated if the message is to be edited. "`#`" can be
- customized with core.commentChar.
+ Same as `whitespace` except that everything from (and including)
+ the line found below is truncated, if the message is to be edited.
+ "`#`" can be customized with core.commentChar.
+
+ # ------------------------ >8 ------------------------
+
default::
Same as `strip` if the message is to be edited.
Otherwise `whitespace`.
diff --git a/en/git-config.txt b/en/git-config.txt
index 83f86b9231b012bbb4716dc27cd72291cb48126a..1bfe9f56a7b9b983a2d927406dc17ff384e715a2 100644
--- a/en/git-config.txt
+++ b/en/git-config.txt
@@ -9,13 +9,13 @@ git-config - Get and set repository or global options
SYNOPSIS
--------
[verse]
-'git config' [<file-option>] [type] [--show-origin] [-z|--null] name [value [value_regex]]
-'git config' [<file-option>] [type] --add name value
-'git config' [<file-option>] [type] --replace-all name value [value_regex]
-'git config' [<file-option>] [type] [--show-origin] [-z|--null] --get name [value_regex]
-'git config' [<file-option>] [type] [--show-origin] [-z|--null] --get-all name [value_regex]
-'git config' [<file-option>] [type] [--show-origin] [-z|--null] [--name-only] --get-regexp name_regex [value_regex]
-'git config' [<file-option>] [type] [-z|--null] --get-urlmatch name URL
+'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] name [value [value_regex]]
+'git config' [<file-option>] [--type=<type>] --add name value
+'git config' [<file-option>] [--type=<type>] --replace-all name value [value_regex]
+'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] --get name [value_regex]
+'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] --get-all name [value_regex]
+'git config' [<file-option>] [--type=<type>] [--show-origin] [-z|--null] [--name-only] --get-regexp name_regex [value_regex]
+'git config' [<file-option>] [--type=<type>] [-z|--null] --get-urlmatch name URL
'git config' [<file-option>] --unset name [value_regex]
'git config' [<file-option>] --unset-all name [value_regex]
'git config' [<file-option>] --rename-section old_name new_name
@@ -38,22 +38,22 @@ existing values that match the regexp are updated or unset. If
you want to handle the lines that do *not* match the regex, just
prepend a single exclamation mark in front (see also <<EXAMPLES>>).
-The type specifier can be either `--int` or `--bool`, to make
-'git config' ensure that the variable(s) are of the given type and
-convert the value to the canonical form (simple decimal number for int,
-a "true" or "false" string for bool), or `--path`, which does some
-path expansion (see `--path` below). If no type specifier is passed, no
-checks or transformations are performed on the value.
+The `--type=<type>` option instructs 'git config' to ensure that incoming and
+outgoing values are canonicalize-able under the given <type>. If no
+`--type=<type>` is given, no canonicalization will be performed. Callers may
+unset an existing `--type` specifier with `--no-type`.
When reading, the values are read from the system, global and
repository local configuration files by default, and options
-`--system`, `--global`, `--local` and `--file <filename>` can be
-used to tell the command to read from only that location (see <<FILES>>).
+`--system`, `--global`, `--local`, `--worktree` and
+`--file <filename>` can be used to tell the command to read from only
+that location (see <<FILES>>).
When writing, the new value is written to the repository local
configuration file by default, and options `--system`, `--global`,
-`--file <filename>` can be used to tell the command to write to
-that location (you can say `--local` but that is the default).
+`--worktree`, `--file <filename>` can be used to tell the command to
+write to that location (you can say `--local` but that is the
+default).
This command will fail with non-zero status upon error. Some exit
codes are:
@@ -133,6 +133,11 @@ from all available files.
+
See also <<FILES>>.
+--worktree::
+ Similar to `--local` except that `.git/config.worktree` is
+ read from or written to if `extensions.worktreeConfig` is
+ present. If not it's the same as `--local`.
+
-f config-file::
--file config-file::
Use the given config file instead of the one specified by GIT_CONFIG.
@@ -160,25 +165,43 @@ See also <<FILES>>.
--list::
List all variables set in config file, along with their values.
---bool::
- 'git config' will ensure that the output is "true" or "false"
+--type <type>::
+ 'git config' will ensure that any input or output is valid under the given
+ type constraint(s), and will canonicalize outgoing values in `<type>`'s
+ canonical form.
++
+Valid `<type>`'s include:
++
+- 'bool': canonicalize values as either "true" or "false".
+- 'int': canonicalize values as simple decimal numbers. An optional suffix of
+ 'k', 'm', or 'g' will cause the value to be multiplied by 1024, 1048576, or
+ 1073741824 upon input.
+- 'bool-or-int': canonicalize according to either 'bool' or 'int', as described
+ above.
+- 'path': canonicalize by adding a leading `~` to the value of `$HOME` and
+ `~user` to the home directory for the specified user. This specifier has no
+ effect when setting the value (but you can use `git config section.variable
+ ~/` from the command line to let your shell do the expansion.)
+- 'expiry-date': canonicalize by converting from a fixed or relative date-string
+ to a timestamp. This specifier has no effect when setting the value.
+- 'color': When getting a value, canonicalize by converting to an ANSI color
+ escape sequence. When setting a value, a sanity-check is performed to ensure
+ that the given value is canonicalize-able as an ANSI color, but it is written
+ as-is.
++
+--bool::
--int::
- 'git config' will ensure that the output is a simple
- decimal number. An optional value suffix of 'k', 'm', or 'g'
- in the config file will cause the value to be multiplied
- by 1024, 1048576, or 1073741824 prior to output.
-
--bool-or-int::
- 'git config' will ensure that the output matches the format of
- either --bool or --int, as described above.
-
--path::
- 'git-config' will expand leading '{tilde}' to the value of
- '$HOME', and '{tilde}user' to the home directory for the
- specified user. This option has no effect when setting the
- value (but you can use 'git config bla {tilde}/' from the
- command line to let your shell do the expansion).
+--expiry-date::
+ Historical options for selecting a type specifier. Prefer instead `--type`
+ (see above).
+
+--no-type::
+ Un-sets the previously set type specifier (if one was previously set). This
+ option requests that 'git config' not canonicalize the retrieved variable.
+ `--no-type` has no effect without `--type=<type>` or `--<type>`.
-z::
--null::
@@ -216,6 +239,8 @@ See also <<FILES>>.
output it as the ANSI color escape sequence to the standard
output. The optional `default` parameter is used instead, if
there is no color configured for `name`.
++
+`--type=color [--default=<default>]` is preferred over `--get-color`.
-e::
--edit::
@@ -228,6 +253,16 @@ See also <<FILES>>.
using `--file`, `--global`, etc) and `on` when searching all
config files.
+--default <value>::
+ When using `--get`, and the requested variable is not found, behave as if
+ <value> were the value assigned to the that variable.
+
+CONFIGURATION
+-------------
+`pager.config` is only respected when listing configuration, i.e., when
+using `--list` or any of the `--get-*` which may return multiple results.
+The default is to use a pager.
+
[[FILES]]
FILES
-----
@@ -253,6 +288,10 @@ $XDG_CONFIG_HOME/git/config::
$GIT_DIR/config::
Repository specific configuration file.
+$GIT_DIR/config.worktree::
+ This is optional and is only searched when
+ `extensions.worktreeConfig` is present in $GIT_DIR/config.
+
If no further options are given, all reading options will read all of these
files that are available. If the global or the system-wide configuration
file are not available they will be ignored. If the repository configuration
@@ -271,9 +310,10 @@ configuration file. Note that this also affects options like `--replace-all`
and `--unset`. *'git config' will only ever change one file at a time*.
You can override these rules either by command-line options or by environment
-variables. The `--global` and the `--system` options will limit the file used
-to the global or system-wide file respectively. The `GIT_CONFIG` environment
-variable has a similar effect, but you can specify any filename you want.
+variables. The `--global`, `--system` and `--worktree` options will limit
+the file used to the global, system-wide or per-worktree file respectively.
+The `GIT_CONFIG` environment variable has a similar effect, but you
+can specify any filename you want.
ENVIRONMENT
@@ -414,9 +454,9 @@ For URLs in `https://weak.example.com`, `http.sslVerify` is set to
false, while it is set to `true` for all others:
------------
-% git config --bool --get-urlmatch http.sslverify https://good.example.com
+% git config --type=bool --get-urlmatch http.sslverify https://good.example.com
true
-% git config --bool --get-urlmatch http.sslverify https://weak.example.com
+% git config --type=bool --get-urlmatch http.sslverify https://weak.example.com
false
% git config --get-urlmatch http https://weak.example.com
http.cookieFile /tmp/cookie.txt
@@ -425,6 +465,27 @@ http.sslverify false
include::config.txt[]
+BUGS
+----
+When using the deprecated `[section.subsection]` syntax, changing a value
+will result in adding a multi-line key instead of a change, if the subsection
+is given with at least one uppercase character. For example when the config
+looks like
+
+--------
+ [section.subsection]
+ key = value1
+--------
+
+and running `git config section.Subsection.key value2` will result in
+
+--------
+ [section.subsection]
+ key = value1
+ key = value2
+--------
+
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/en/git-credential-cache.txt b/en/git-credential-cache.txt
index 96208f822e0995f97664423038abe1f406431986..0216c18ef80c9a9d32095ec3969091aff1c20344 100644
--- a/en/git-credential-cache.txt
+++ b/en/git-credential-cache.txt
@@ -8,7 +8,7 @@ git-credential-cache - Helper to temporarily store passwords in memory
SYNOPSIS
--------
-----------------------------
-git config credential.helper 'cache [options]'
+git config credential.helper 'cache [<options>]'
-----------------------------
DESCRIPTION
@@ -33,10 +33,13 @@ OPTIONS
--socket <path>::
Use `<path>` to contact a running cache daemon (or start a new
- cache daemon if one is not started). Defaults to
- `~/.git-credential-cache/socket`. If your home directory is on a
- network-mounted filesystem, you may need to change this to a
- local filesystem. You must specify an absolute path.
+ cache daemon if one is not started).
+ Defaults to `$XDG_CACHE_HOME/git/credential/socket` unless
+ `~/.git-credential-cache/` exists in which case
+ `~/.git-credential-cache/socket` is used instead.
+ If your home directory is on a network-mounted filesystem, you
+ may need to change this to a local filesystem. You must specify
+ an absolute path.
CONTROLLING THE DAEMON
----------------------
diff --git a/en/git-credential-store.txt b/en/git-credential-store.txt
index 25fb963f4b06695bb0c5fcf9a1feed97dfc549ed..693dd9d9d760fe2a113d4e15ab7816f34b2cd47d 100644
--- a/en/git-credential-store.txt
+++ b/en/git-credential-store.txt
@@ -8,7 +8,7 @@ git-credential-store - Helper to store credentials on disk
SYNOPSIS
--------
-------------------
-git config credential.helper 'store [options]'
+git config credential.helper 'store [<options>]'
-------------------
DESCRIPTION
diff --git a/en/git-cvsserver.txt b/en/git-cvsserver.txt
index a336ae5f6fd5587aa8f778d2378783d0fe2e6dc4..f98b7c6ed7c0fe4df8a0e3211eaa53ea7c95d5d9 100644
--- a/en/git-cvsserver.txt
+++ b/en/git-cvsserver.txt
@@ -22,7 +22,7 @@ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
Usage:
[verse]
-'git-cvsserver' [options] [pserver|server] [<directory> ...]
+'git-cvsserver' [<options>] [pserver|server] [<directory> ...]
OPTIONS
-------
@@ -207,7 +207,7 @@ allowing access over SSH.
------
[[dbbackend]]
-Database Backend
+DATABASE BACKEND
----------------
'git-cvsserver' uses one database per Git head (i.e. CVS module) to
@@ -223,7 +223,7 @@ access method and requested operation.
That means that even if you offer only read access (e.g. by using
the pserver method), 'git-cvsserver' should have write access to
the database to work reliably (otherwise you need to make sure
-that the database is up-to-date any time 'git-cvsserver' is executed).
+that the database is up to date any time 'git-cvsserver' is executed).
By default it uses SQLite databases in the Git directory, named
`gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates
@@ -321,7 +321,7 @@ git-cvsserver, as described above.
When these environment variables are set, the corresponding
command-line arguments may not be used.
-Eclipse CVS Client Notes
+ECLIPSE CVS CLIENT NOTES
------------------------
To get a checkout with the Eclipse CVS client:
@@ -346,7 +346,7 @@ offer. In that case CVS_SERVER is ignored, and you will have to replace
the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc`
so that calling 'cvs' effectively calls 'git-cvsserver'.
-Clients known to work
+CLIENTS KNOWN TO WORK
---------------------
- CVS 1.12.9 on Debian
@@ -354,7 +354,7 @@ Clients known to work
- Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
- TortoiseCVS
-Operations supported
+OPERATIONS SUPPORTED
--------------------
All the operations required for normal use are supported, including
@@ -424,7 +424,7 @@ For best consistency with 'cvs', it is probably best to override the
defaults by setting `gitcvs.usecrlfattr` to true,
and `gitcvs.allBinary` to "guess".
-Dependencies
+DEPENDENCIES
------------
'git-cvsserver' depends on DBD::SQLite.
diff --git a/en/git-daemon.txt b/en/git-daemon.txt
index 3c91db7bed038f7ba28a4e7554cc6e63c5d91958..56d54a489875652e754f7cd16ee5a77c2f5e5202 100644
--- a/en/git-daemon.txt
+++ b/en/git-daemon.txt
@@ -20,6 +20,7 @@ SYNOPSIS
[--inetd |
[--listen=<host_or_ipaddr>] [--port=<n>]
[--user=<user> [--group=<group>]]]
+ [--log-destination=(stderr|syslog|none)]
[<directory>...]
DESCRIPTION
@@ -80,7 +81,8 @@ OPTIONS
do not have the 'git-daemon-export-ok' file.
--inetd::
- Have the server run as an inetd service. Implies --syslog.
+ Have the server run as an inetd service. Implies --syslog (may be
+ overridden with `--log-destination=`).
Incompatible with --detach, --port, --listen, --user and --group
options.
@@ -110,8 +112,28 @@ OPTIONS
zero for no limit.
--syslog::
- Log to syslog instead of stderr. Note that this option does not imply
- --verbose, thus by default only error conditions will be logged.
+ Short for `--log-destination=syslog`.
+
+--log-destination=<destination>::
+ Send log messages to the specified destination.
+ Note that this option does not imply --verbose,
+ thus by default only error conditions will be logged.
+ The <destination> must be one of:
++
+--
+stderr::
+ Write to standard error.
+ Note that if `--detach` is specified,
+ the process disconnects from the real standard error,
+ making this destination effectively equivalent to `none`.
+syslog::
+ Write to syslog, using the `git-daemon` identifier.
+none::
+ Disable all logging.
+--
++
+The default destination is `syslog` if `--inetd` or `--detach` is specified,
+otherwise `stderr`.
--user-path::
--user-path=<path>::
diff --git a/en/git-describe.txt b/en/git-describe.txt
index 8755f3af7bcd16b564fdd01563e36d3cc4103c07..ccdc5f83d6dcd297f1e4922b27b904f00d6f4721 100644
--- a/en/git-describe.txt
+++ b/en/git-describe.txt
@@ -3,14 +3,14 @@ git-describe(1)
NAME
----
-git-describe - Describe a commit using the most recent tag reachable from it
-
+git-describe - Give an object a human readable name based on an available ref
SYNOPSIS
--------
[verse]
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>...]
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
+'git describe' <blob>
DESCRIPTION
-----------
@@ -18,21 +18,34 @@ The command finds the most recent tag that is reachable from a
commit. If the tag points to the commit, then only the tag is
shown. Otherwise, it suffixes the tag name with the number of
additional commits on top of the tagged object and the
-abbreviated object name of the most recent commit.
+abbreviated object name of the most recent commit. The result
+is a "human-readable" object name which can also be used to
+identify the commit to other git commands.
By default (without --all or --tags) `git describe` only shows
annotated tags. For more information about creating annotated tags
see the -a and -s options to linkgit:git-tag[1].
+If the given object refers to a blob, it will be described
+as `<commit-ish>:<path>`, such that the blob can be found
+at `<path>` in the `<commit-ish>`, which itself describes the
+first commit in which this blob occurs in a reverse revision walk
+from HEAD.
+
OPTIONS
-------
<commit-ish>...::
Commit-ish object names to describe. Defaults to HEAD if omitted.
--dirty[=<mark>]::
- Describe the working tree.
- It means describe HEAD and appends <mark> (`-dirty` by
- default) if the working tree is dirty.
+--broken[=<mark>]::
+ Describe the state of the working tree. When the working
+ tree matches HEAD, the output is the same as "git describe
+ HEAD". If the working tree has local modification "-dirty"
+ is appended to it. If a repository is corrupt and Git
+ cannot determine if there is local modification, Git will
+ error out, unless `--broken' is given, which appends
+ the suffix "-broken" instead.
--all::
Instead of using only the annotated tags, use any ref
@@ -82,19 +95,23 @@ OPTIONS
--match <pattern>::
Only consider tags matching the given `glob(7)` pattern,
- excluding the "refs/tags/" prefix. This can be used to avoid
- leaking private tags from the repository. If given multiple times, a
- list of patterns will be accumulated, and tags matching any of the
- patterns will be considered. Use `--no-match` to clear and reset the
- list of patterns.
+ excluding the "refs/tags/" prefix. If used with `--all`, it also
+ considers local branches and remote-tracking references matching the
+ pattern, excluding respectively "refs/heads/" and "refs/remotes/"
+ prefix; references of other types are never considered. If given
+ multiple times, a list of patterns will be accumulated, and tags
+ matching any of the patterns will be considered. Use `--no-match` to
+ clear and reset the list of patterns.
--exclude <pattern>::
Do not consider tags matching the given `glob(7)` pattern, excluding
- the "refs/tags/" prefix. This can be used to narrow the tag space and
- find only tags matching some meaningful criteria. If given multiple
- times, a list of patterns will be accumulated and tags matching any
- of the patterns will be excluded. When combined with --match a tag will
- be considered when it matches at least one --match pattern and does not
+ the "refs/tags/" prefix. If used with `--all`, it also does not consider
+ local branches and remote-tracking references matching the pattern,
+ excluding respectively "refs/heads/" and "refs/remotes/" prefix;
+ references of other types are never considered. If given multiple times,
+ a list of patterns will be accumulated and tags matching any of the
+ patterns will be excluded. When combined with --match a tag will be
+ considered when it matches at least one --match pattern and does not
match any of the --exclude patterns. Use `--no-exclude` to clear and
reset the list of patterns.
@@ -177,6 +194,14 @@ selected and output. Here fewest commits different is defined as
the number of commits which would be shown by `git log tag..input`
will be the smallest number of commits possible.
+BUGS
+----
+
+Tree objects as well as tag objects not pointing at commits, cannot be described.
+When describing blobs, the lightweight tags pointing at blobs are ignored,
+but the blob is still described as <committ-ish>:<path> despite the lightweight
+tag being favorable.
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/en/git-diff-index.txt b/en/git-diff-index.txt
index a1715069529eba9d143d527c058e962381efd743..f4bd8155c0a707308162e050d5d59b5dbd5ca7a6 100644
--- a/en/git-diff-index.txt
+++ b/en/git-diff-index.txt
@@ -37,14 +37,14 @@ include::diff-options.txt[]
include::diff-format.txt[]
-Operating Modes
+OPERATING MODES
---------------
You can choose whether you want to trust the index file entirely
(using the `--cached` flag) or ask the diff logic to show any files
that don't match the stat state as being "tentatively changed". Both
of these operations are very useful indeed.
-Cached Mode
+CACHED MODE
-----------
If `--cached` is specified, it allows you to ask:
@@ -77,7 +77,7 @@ So doing a `git diff-index --cached` is basically very useful when you are
asking yourself "what have I already marked for being committed, and
what's the difference to a previous tree".
-Non-cached Mode
+NON-CACHED MODE
---------------
The "non-cached" mode takes a different approach, and is potentially
the more useful of the two in that what it does can't be emulated with
@@ -85,7 +85,7 @@ a 'git write-tree' + 'git diff-tree'. Thus that's the default mode.
The non-cached version asks the question:
show me the differences between HEAD and the currently checked out
- tree - index contents _and_ files that aren't up-to-date
+ tree - index contents _and_ files that aren't up to date
which is obviously a very useful question too, since that tells you what
you *could* commit. Again, the output matches the 'git diff-tree -r'
@@ -100,8 +100,8 @@ have not actually done a 'git update-index' on it yet - there is no
torvalds@ppc970:~/v2.6/linux> git diff-index --abbrev HEAD
:100644 100664 7476bb... 000000... kernel/sched.c
-i.e., it shows that the tree has changed, and that `kernel/sched.c` has is
-not up-to-date and may contain new stuff. The all-zero sha1 means that to
+i.e., it shows that the tree has changed, and that `kernel/sched.c` is
+not up to date and may contain new stuff. The all-zero sha1 means that to
get the real diff, you need to look at the object in the working directory
directly rather than do an object-to-object diff.
diff --git a/en/git-diff-tree.txt b/en/git-diff-tree.txt
index 7870e175b7683ffcdbdc98d3f669998c615c2ffd..43daa7c046f472ac856d89292ede96f5e5dcb64e 100644
--- a/en/git-diff-tree.txt
+++ b/en/git-diff-tree.txt
@@ -31,10 +31,7 @@ include::diff-options.txt[]
<path>...::
If provided, the results are limited to a subset of files
- matching one of these prefix strings.
- i.e., file matches `/^<pattern1>|<pattern2>|.../`
- Note that this parameter does not provide any wildcard or regexp
- features.
+ matching one of the provided pathspecs.
-r::
recurse into sub-trees
@@ -114,52 +111,6 @@ include::pretty-options.txt[]
include::pretty-formats.txt[]
-
-
-Limiting Output
----------------
-If you're only interested in differences in a subset of files, for
-example some architecture-specific files, you might do:
-
- git diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
-
-and it will only show you what changed in those two directories.
-
-Or if you are searching for what changed in just `kernel/sched.c`, just do
-
- git diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
-
-and it will ignore all differences to other files.
-
-The pattern is always the prefix, and is matched exactly. There are no
-wildcards. Even stricter, it has to match a complete path component.
-I.e. "foo" does not pick up `foobar.h`. "foo" does match `foo/bar.h`
-so it can be used to name subdirectories.
-
-An example of normal usage is:
-
- torvalds@ppc970:~/git> git diff-tree --abbrev 5319e4
- :100664 100664 ac348b... a01513... git-fsck-objects.c
-
-which tells you that the last commit changed just one file (it's from
-this one:
-
------------------------------------------------------------------------------
-commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8
-tree 5319e4d609cdd282069cc4dce33c1db559539b03
-parent b4e628ea30d5ab3606119d2ea5caeab141d38df7
-author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
-committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
-
-Make "git-fsck-objects" print out all the root commits it finds.
-
-Once I do the reference tracking, I'll also make it print out all the
-HEAD commits it finds, which is even more interesting.
------------------------------------------------------------------------------
-
-in case you care).
-
-
include::diff-format.txt[]
GIT
diff --git a/en/git-diff.txt b/en/git-diff.txt
index bbab35fcaff35ccd5459251550924a42ce2c871e..72179d993cb9b68766e2d9093f323cb3720e38f4 100644
--- a/en/git-diff.txt
+++ b/en/git-diff.txt
@@ -9,11 +9,11 @@ git-diff - Show changes between commits, commit and working tree, etc
SYNOPSIS
--------
[verse]
-'git diff' [options] [<commit>] [--] [<path>...]
-'git diff' [options] --cached [<commit>] [--] [<path>...]
-'git diff' [options] <commit> <commit> [--] [<path>...]
-'git diff' [options] <blob> <blob>
-'git diff' [options] [--no-index] [--] <path> <path>
+'git diff' [<options>] [<commit>] [--] [<path>...]
+'git diff' [<options>] --cached [<commit>] [--] [<path>...]
+'git diff' [<options>] <commit> <commit> [--] [<path>...]
+'git diff' [<options>] <blob> <blob>
+'git diff' [<options>] --no-index [--] <path> <path>
DESCRIPTION
-----------
@@ -21,7 +21,7 @@ Show changes between the working tree and the index or a tree, changes
between the index and a tree, changes between two trees, changes between
two blob objects, or changes between two files on disk.
-'git diff' [--options] [--] [<path>...]::
+'git diff' [<options>] [--] [<path>...]::
This form is to view the changes you made relative to
the index (staging area for the next commit). In other
@@ -29,7 +29,7 @@ two blob objects, or changes between two files on disk.
further add to the index but you still haven't. You can
stage these changes by using linkgit:git-add[1].
-'git diff' --no-index [--options] [--] [<path>...]::
+'git diff' [<options>] --no-index [--] <path> <path>::
This form is to compare the given two paths on the
filesystem. You can omit the `--no-index` option when
@@ -38,7 +38,7 @@ two blob objects, or changes between two files on disk.
or when running the command outside a working tree
controlled by Git.
-'git diff' [--options] --cached [<commit>] [--] [<path>...]::
+'git diff' [<options>] --cached [<commit>] [--] [<path>...]::
This form is to view the changes you staged for the next
commit relative to the named <commit>. Typically you
@@ -48,7 +48,7 @@ two blob objects, or changes between two files on disk.
<commit> is not given, it shows all staged changes.
--staged is a synonym of --cached.
-'git diff' [--options] <commit> [--] [<path>...]::
+'git diff' [<options>] <commit> [--] [<path>...]::
This form is to view the changes you have in your
working tree relative to the named <commit>. You can
@@ -56,26 +56,26 @@ two blob objects, or changes between two files on disk.
branch name to compare with the tip of a different
branch.
-'git diff' [--options] <commit> <commit> [--] [<path>...]::
+'git diff' [<options>] <commit> <commit> [--] [<path>...]::
This is to view the changes between two arbitrary
<commit>.
-'git diff' [--options] <commit>..<commit> [--] [<path>...]::
+'git diff' [<options>] <commit>..<commit> [--] [<path>...]::
This is synonymous to the previous form. If <commit> on
one side is omitted, it will have the same effect as
using HEAD instead.
-'git diff' [--options] <commit>\...<commit> [--] [<path>...]::
+'git diff' [<options>] <commit>\...<commit> [--] [<path>...]::
This form is to view the changes on the branch containing
and up to the second <commit>, starting at a common ancestor
of both <commit>. "git diff A\...B" is equivalent to
- "git diff $(git-merge-base A B) B". You can omit any one
+ "git diff $(git merge-base A B) B". You can omit any one
of <commit>, which has the same effect as using HEAD instead.
-Just in case if you are doing something exotic, it should be
+Just in case you are doing something exotic, it should be
noted that all of the <commit> in the above description, except
in the last two forms that use ".." notations, can be any
<tree>.
@@ -87,7 +87,7 @@ and the range notations ("<commit>..<commit>" and
"<commit>\...<commit>") do not mean a range as defined in the
"SPECIFYING RANGES" section in linkgit:gitrevisions[7].
-'git diff' [options] <blob> <blob>::
+'git diff' [<options>] <blob> <blob>::
This form is to view the differences between the raw
contents of two blob objects.
@@ -97,6 +97,20 @@ OPTIONS
:git-diff: 1
include::diff-options.txt[]
+-1 --base::
+-2 --ours::
+-3 --theirs::
+ Compare the working tree with the "base" version (stage #1),
+ "our branch" (stage #2) or "their branch" (stage #3). The
+ index contains these stages only for unmerged entries i.e.
+ while resolving conflicts. See linkgit:git-read-tree[1]
+ section "3-Way Merge" for detailed information.
+
+-0::
+ Omit diff output for unmerged entries and just show
+ "Unmerged". Can be used only when comparing the working tree
+ with the index.
+
<path>...::
The <paths> parameters, when given, are used to limit
the diff to the named paths (you can give directory
@@ -118,9 +132,9 @@ $ git diff HEAD <3>
+
<1> Changes in the working tree not yet staged for the next commit.
<2> Changes between the index and your last commit; what you
-would be committing if you run "git commit" without "-a" option.
+ would be committing if you run "git commit" without "-a" option.
<3> Changes in the working tree since your last commit; what you
-would be committing if you run "git commit -a"
+ would be committing if you run "git commit -a"
Comparing with arbitrary commits::
+
@@ -131,10 +145,10 @@ $ git diff HEAD^ HEAD <3>
------------
+
<1> Instead of using the tip of the current branch, compare with the
-tip of "test" branch.
+ tip of "test" branch.
<2> Instead of comparing with the tip of "test" branch, compare with
-the tip of the current branch, but limit the comparison to the
-file "test".
+ the tip of the current branch, but limit the comparison to the
+ file "test".
<3> Compare the version before the last commit and the last commit.
Comparing branches::
@@ -148,7 +162,7 @@ $ git diff topic...master <3>
<1> Changes between the tips of the topic and the master branches.
<2> Same as above.
<3> Changes that occurred on the master branch since when the topic
-branch was started off it.
+ branch was started off it.
Limiting the diff output::
+
@@ -159,9 +173,9 @@ $ git diff arch/i386 include/asm-i386 <3>
------------
+
<1> Show only modification, rename, and copy, but not addition
-or deletion.
+ or deletion.
<2> Show only names and the nature of change, but not actual
-diff output.
+ diff output.
<3> Limit diff output to named subtrees.
Munging the diff output::
@@ -172,7 +186,7 @@ $ git diff -R <2>
------------
+
<1> Spend extra cycles to find renames, copies and complete
-rewrites (very expensive).
+ rewrites (very expensive).
<2> Output diff in reverse.
SEE ALSO
diff --git a/en/git-fast-export.txt b/en/git-fast-export.txt
index ed57c684dbc82c587ca1cf6b66ae46f3760ecfba..64c01ba91884df1ec8e49ddc8fe852f1fb2a9425 100644
--- a/en/git-fast-export.txt
+++ b/en/git-fast-export.txt
@@ -9,7 +9,7 @@ git-fast-export - Git data exporter
SYNOPSIS
--------
[verse]
-'git fast-export [options]' | 'git fast-import'
+'git fast-export [<options>]' | 'git fast-import'
DESCRIPTION
-----------
@@ -110,6 +110,25 @@ marks the same across runs.
the shape of the history and stored tree. See the section on
`ANONYMIZING` below.
+--reference-excluded-parents::
+ By default, running a command such as `git fast-export
+ master~5..master` will not include the commit master{tilde}5
+ and will make master{tilde}4 no longer have master{tilde}5 as
+ a parent (though both the old master{tilde}4 and new
+ master{tilde}4 will have all the same files). Use
+ --reference-excluded-parents to instead have the the stream
+ refer to commits in the excluded range of history by their
+ sha1sum. Note that the resulting stream can only be used by a
+ repository which already contains the necessary parent
+ commits.
+
+--show-original-ids::
+ Add an extra directive to the output for commits and blobs,
+ `original-oid <SHA1SUM>`. While such directives will likely be
+ ignored by importers such as git-fast-import, it may be useful
+ for intermediary filters (e.g. for rewriting commit messages
+ which refer to older commits, or for stripping blobs by id).
+
--refspec::
Apply the specified refspec to each ref exported. Multiple of them can
be specified.
@@ -119,7 +138,9 @@ marks the same across runs.
'git rev-list', that specifies the specific objects and references
to export. For example, `master~10..master` causes the
current master reference to be exported along with all objects
- added since its 10th ancestor commit.
+ added since its 10th ancestor commit and (unless the
+ --reference-excluded-parents option is specified) all files
+ common to master{tilde}9 and master{tilde}10.
EXAMPLES
--------
@@ -202,7 +223,7 @@ smaller output, and it is usually easy to quickly confirm that there is
no private data in the stream.
-Limitations
+LIMITATIONS
-----------
Since 'git fast-import' cannot tag trees, you will not be
diff --git a/en/git-fast-import.txt b/en/git-fast-import.txt
index 2b762654bf4779b8579bf9b17e75b4aa0322f789..43ab3b1637b50462ff62aa9c33c87184ef8ebc47 100644
--- a/en/git-fast-import.txt
+++ b/en/git-fast-import.txt
@@ -9,7 +9,7 @@ git-fast-import - Backend for fast Git data importers
SYNOPSIS
--------
[verse]
-frontend | 'git fast-import' [options]
+frontend | 'git fast-import' [<options>]
DESCRIPTION
-----------
@@ -40,9 +40,10 @@ OPTIONS
not contain the old commit).
--quiet::
- Disable all non-fatal output, making fast-import silent when it
- is successful. This option disables the output shown by
- --stats.
+ Disable the output shown by --stats, making fast-import usually
+ be silent when it is successful. However, if the import stream
+ has directives intended to show user output (e.g. `progress`
+ directives), the corresponding messages will still be shown.
--stats::
Display some basic statistics about the objects fast-import has
@@ -121,7 +122,7 @@ Performance and Compression Tuning
--depth=<n>::
Maximum delta depth, for blob and tree deltification.
- Default is 10.
+ Default is 50.
--export-pack-edges=<file>::
After creating a packfile, print a line of data to
@@ -139,7 +140,7 @@ Performance and Compression Tuning
fastimport.unpackLimit::
See linkgit:git-config[1]
-Performance
+PERFORMANCE
-----------
The design of fast-import allows it to import large projects in a minimum
amount of memory usage and processing time. Assuming the frontend
@@ -155,7 +156,7 @@ faster if the source data is stored on a different drive than the
destination Git repository (due to less IO contention).
-Development Cost
+DEVELOPMENT COST
----------------
A typical frontend for fast-import tends to weigh in at approximately 200
lines of Perl/Python/Ruby code. Most developers have been able to
@@ -165,7 +166,7 @@ an ideal situation, given that most conversion tools are throw-away
(use once, and never look back).
-Parallel Operation
+PARALLEL OPERATION
------------------
Like 'git push' or 'git fetch', imports handled by fast-import are safe to
run alongside parallel `git repack -a -d` or `git gc` invocations,
@@ -186,7 +187,7 @@ this only be used on an otherwise quiet repository. Using --force
is not necessary for an initial import into an empty repository.
-Technical Discussion
+TECHNICAL DISCUSSION
--------------------
fast-import tracks a set of branches in memory. Any branch can be created
or modified at any point during the import process by sending a
@@ -204,7 +205,7 @@ directory also allows fast-import to run very quickly, as it does not
need to perform any costly file update operations when switching
between branches.
-Input Format
+INPUT FORMAT
------------
With the exception of raw file data (which Git does not interpret)
the fast-import input format is text (ASCII) based. This text based
@@ -384,6 +385,7 @@ change to the project.
....
'commit' SP <ref> LF
mark?
+ original-oid?
('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
'committer' (SP <name>)? SP LT <email> GT SP <when> LF
data
@@ -740,6 +742,19 @@ New marks are created automatically. Existing marks can be moved
to another object simply by reusing the same `<idnum>` in another
`mark` command.
+`original-oid`
+~~~~~~~~~~~~~~
+Provides the name of the object in the original source control system.
+fast-import will simply ignore this directive, but filter processes
+which operate on and modify the stream before feeding to fast-import
+may have uses for this information
+
+....
+ 'original-oid' SP <object-identifier> LF
+....
+
+where `<object-identifer>` is any string not containing LF.
+
`tag`
~~~~~
Creates an annotated tag referring to a specific commit. To create
@@ -748,6 +763,7 @@ lightweight (non-annotated) tags see the `reset` command below.
....
'tag' SP <name> LF
'from' SP <commit-ish> LF
+ original-oid?
'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
data
....
@@ -822,6 +838,7 @@ assigned mark.
....
'blob' LF
mark?
+ original-oid?
data
....
@@ -1131,7 +1148,7 @@ If the `--done` command-line option or `feature done` command is
in use, the `done` command is mandatory and marks the end of the
stream.
-Responses To Commands
+RESPONSES TO COMMANDS
---------------------
New objects written by fast-import are not available immediately.
Most fast-import commands have no visible effect until the next
@@ -1160,7 +1177,7 @@ To avoid deadlock, such frontends must completely consume any
pending output from `progress`, `ls`, `get-mark`, and `cat-blob` before
performing writes to fast-import that might block.
-Crash Reports
+CRASH REPORTS
-------------
If fast-import is supplied invalid input it will terminate with a
non-zero exit status and create a crash report in the top level of
@@ -1247,7 +1264,7 @@ An example crash:
END OF CRASH REPORT
====
-Tips and Tricks
+TIPS AND TRICKS
---------------
The following tips and tricks have been collected from various
users of fast-import, and are offered here as suggestions.
@@ -1349,7 +1366,7 @@ Your users will feel better knowing how much of the data stream
has been processed.
-Packfile Optimization
+PACKFILE OPTIMIZATION
---------------------
When packing a blob fast-import always attempts to deltify against the last
blob written. Unless specifically arranged for by the frontend,
@@ -1380,7 +1397,7 @@ to force recomputation of all deltas can significantly reduce the
final packfile size (30-50% smaller can be quite typical).
-Memory Utilization
+MEMORY UTILIZATION
------------------
There are a number of factors which affect how much memory fast-import
requires to perform an import. Like critical sections of core
@@ -1458,7 +1475,7 @@ and lazy loading of subtrees, allows fast-import to efficiently import
projects with 2,000+ branches and 45,114+ files in a very limited
memory footprint (less than 2.7 MiB per active branch).
-Signals
+SIGNALS
-------
Sending *SIGUSR1* to the 'git fast-import' process ends the current
packfile early, simulating a `checkpoint` command. The impatient
diff --git a/en/git-fetch-pack.txt b/en/git-fetch-pack.txt
index f7ebe36a7b2c203e0b2f320309a5ce6250b12471..c9758847937e7db9fb3c4c3a498f5074e9e1f5d9 100644
--- a/en/git-fetch-pack.txt
+++ b/en/git-fetch-pack.txt
@@ -88,7 +88,7 @@ be in a separate packet, and the list must end with a flush packet.
infinite even if there is an ancestor-chain that long.
--shallow-since=<date>::
- Deepen or shorten the history of a shallow'repository to
+ Deepen or shorten the history of a shallow repository to
include all reachable commits after <date>.
--shallow-exclude=<revision>::
diff --git a/en/git-fetch.txt b/en/git-fetch.txt
index b153aefa68c8dcaa5f3600d67c5ff0010ee899af..266d63cf111c8a73420c5fa945543384e9825b55 100644
--- a/en/git-fetch.txt
+++ b/en/git-fetch.txt
@@ -99,6 +99,93 @@ The latter use of the `remote.<repository>.fetch` values can be
overridden by giving the `--refmap=<refspec>` parameter(s) on the
command line.
+PRUNING
+-------
+
+Git has a default disposition of keeping data unless it's explicitly
+thrown away; this extends to holding onto local references to branches
+on remotes that have themselves deleted those branches.
+
+If left to accumulate, these stale references might make performance
+worse on big and busy repos that have a lot of branch churn, and
+e.g. make the output of commands like `git branch -a --contains
+<commit>` needlessly verbose, as well as impacting anything else
+that'll work with the complete set of known references.
+
+These remote-tracking references can be deleted as a one-off with
+either of:
+
+------------------------------------------------
+# While fetching
+$ git fetch --prune <name>
+
+# Only prune, don't fetch
+$ git remote prune <name>
+------------------------------------------------
+
+To prune references as part of your normal workflow without needing to
+remember to run that, set `fetch.prune` globally, or
+`remote.<name>.prune` per-remote in the config. See
+linkgit:git-config[1].
+
+Here's where things get tricky and more specific. The pruning feature
+doesn't actually care about branches, instead it'll prune local <->
+remote-references as a function of the refspec of the remote (see
+`<refspec>` and <<CRTB,CONFIGURED REMOTE-TRACKING BRANCHES>> above).
+
+Therefore if the refspec for the remote includes
+e.g. `refs/tags/*:refs/tags/*`, or you manually run e.g. `git fetch
+--prune <name> "refs/tags/*:refs/tags/*"` it won't be stale remote
+tracking branches that are deleted, but any local tag that doesn't
+exist on the remote.
+
+This might not be what you expect, i.e. you want to prune remote
+`<name>`, but also explicitly fetch tags from it, so when you fetch
+from it you delete all your local tags, most of which may not have
+come from the `<name>` remote in the first place.
+
+So be careful when using this with a refspec like
+`refs/tags/*:refs/tags/*`, or any other refspec which might map
+references from multiple remotes to the same local namespace.
+
+Since keeping up-to-date with both branches and tags on the remote is
+a common use-case the `--prune-tags` option can be supplied along with
+`--prune` to prune local tags that don't exist on the remote, and
+force-update those tags that differ. Tag pruning can also be enabled
+with `fetch.pruneTags` or `remote.<name>.pruneTags` in the config. See
+linkgit:git-config[1].
+
+The `--prune-tags` option is equivalent to having
+`refs/tags/*:refs/tags/*` declared in the refspecs of the remote. This
+can lead to some seemingly strange interactions:
+
+------------------------------------------------
+# These both fetch tags
+$ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
+$ git fetch --no-tags --prune-tags origin
+------------------------------------------------
+
+The reason it doesn't error out when provided without `--prune` or its
+config versions is for flexibility of the configured versions, and to
+maintain a 1=1 mapping between what the command line flags do, and
+what the configuration versions do.
+
+It's reasonable to e.g. configure `fetch.pruneTags=true` in
+`~/.gitconfig` to have tags pruned whenever `git fetch --prune` is
+run, without making every invocation of `git fetch` without `--prune`
+an error.
+
+Pruning tags with `--prune-tags` also works when fetching a URL
+instead of a named remote. These will all prune tags not found on
+origin:
+
+------------------------------------------------
+$ git fetch origin --prune --prune-tags
+$ git fetch origin --prune 'refs/tags/*:refs/tags/*'
+$ git fetch <url of origin> --prune --prune-tags
+$ git fetch <url of origin> --prune 'refs/tags/*:refs/tags/*'
+------------------------------------------------
+
OUTPUT
------
@@ -179,7 +266,7 @@ The `pu` branch will be updated even if it is does not fast-forward,
because it is prefixed with a plus sign; `tmp` will not be.
* Peek at a remote's branch, without configuring the remote in your local
-repository:
+ repository:
+
------------------------------------------------
$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
diff --git a/en/git-filter-branch.txt b/en/git-filter-branch.txt
index 6e4bb022043faeddd363c899872e7de96c926c1c..e6f08ab189489ec1631169d0ad0b190428883235 100644
--- a/en/git-filter-branch.txt
+++ b/en/git-filter-branch.txt
@@ -8,13 +8,13 @@ git-filter-branch - Rewrite branches
SYNOPSIS
--------
[verse]
-'git filter-branch' [--env-filter <command>] [--tree-filter <command>]
+'git filter-branch' [--setup <command>] [--subdirectory-filter <directory>]
+ [--env-filter <command>] [--tree-filter <command>]
[--index-filter <command>] [--parent-filter <command>]
[--msg-filter <command>] [--commit-filter <command>]
- [--tag-name-filter <command>] [--subdirectory-filter <directory>]
- [--prune-empty]
+ [--tag-name-filter <command>] [--prune-empty]
[--original <namespace>] [-d <directory>] [-f | --force]
- [--] [<rev-list options>...]
+ [--state-branch <branch>] [--] [<rev-list options>...]
DESCRIPTION
-----------
@@ -82,12 +82,23 @@ multiple commits.
OPTIONS
-------
+--setup <command>::
+ This is not a real filter executed for each commit but a one
+ time setup just before the loop. Therefore no commit-specific
+ variables are defined yet. Functions or variables defined here
+ can be used or modified in the following filter steps except
+ the commit filter, for technical reasons.
+
+--subdirectory-filter <directory>::
+ Only look at the history which touches the given subdirectory.
+ The result will contain that directory (and only that) as its
+ project root. Implies <<Remap_to_ancestor>>.
+
--env-filter <command>::
This filter may be used if you only need to modify the environment
in which the commit will be performed. Specifically, you might
want to rewrite the author/committer name/email/time environment
- variables (see linkgit:git-commit-tree[1] for details). Do not forget
- to re-export the variables.
+ variables (see linkgit:git-commit-tree[1] for details).
--tree-filter <command>::
This is the filter for rewriting the tree and its contents.
@@ -161,11 +172,6 @@ be removed, buyer beware. There is also no support for changing the
author or timestamp (or the tag message for that matter). Tags which point
to other tags will be rewritten to point to the underlying commit.
---subdirectory-filter <directory>::
- Only look at the history which touches the given subdirectory.
- The result will contain that directory (and only that) as its
- project root. Implies <<Remap_to_ancestor>>.
-
--prune-empty::
Some filters will generate empty commits that leave the tree untouched.
This option instructs git-filter-branch to remove such commits if they
@@ -192,6 +198,12 @@ to other tags will be rewritten to point to the underlying commit.
directory or when there are already refs starting with
'refs/original/', unless forced.
+--state-branch <branch>::
+ This option will cause the mapping from old to new objects to
+ be loaded from named branch upon startup and saved as a new
+ commit to that branch upon exit, enabling incremental of large
+ trees. If '<branch>' does not exist it will be created.
+
<rev-list options>...::
Arguments for 'git rev-list'. All positive refs included by
these options are rewritten. You may also specify options
@@ -210,7 +222,15 @@ this purpose, they are instead rewritten to point at the nearest ancestor that
was not excluded.
-Examples
+EXIT STATUS
+-----------
+
+On success, the exit status is `0`. If the filter can't find any commits to
+rewrite, the exit status is `2`. On any other error, the exit status may be
+any other non-zero value.
+
+
+EXAMPLES
--------
Suppose you want to remove a file (containing confidential information
@@ -268,7 +288,7 @@ git filter-branch --parent-filter \
or even simpler:
-----------------------------------------------
-echo "$commit-id $graft-id" >> .git/info/grafts
+git replace --graft $commit-id $graft-id
git filter-branch $graft-id..HEAD
-----------------------------------------------
@@ -340,12 +360,10 @@ git filter-branch --env-filter '
if test "$GIT_AUTHOR_EMAIL" = "root@localhost"
then
GIT_AUTHOR_EMAIL=john@example.com
- export GIT_AUTHOR_EMAIL
fi
if test "$GIT_COMMITTER_EMAIL" = "root@localhost"
then
GIT_COMMITTER_EMAIL=john@example.com
- export GIT_COMMITTER_EMAIL
fi
' -- --all
--------------------------------------------------------
@@ -388,7 +406,7 @@ git filter-branch --index-filter \
-Checklist for Shrinking a Repository
+CHECKLIST FOR SHRINKING A REPOSITORY
------------------------------------
git-filter-branch can be used to get rid of a subset of files,
@@ -427,7 +445,7 @@ warned.
(or if your git-gc is not new enough to support arguments to
`--prune`, use `git repack -ad; git prune` instead).
-Notes
+NOTES
-----
git-filter-branch allows you to make complex shell-scripted rewrites
diff --git a/en/git-fmt-merge-msg.txt b/en/git-fmt-merge-msg.txt
index 44892c447e79f1d06435357b30f4ddbbb465e5f1..6793d8fc05218f61ebc399b9ac910f27832bc58b 100644
--- a/en/git-fmt-merge-msg.txt
+++ b/en/git-fmt-merge-msg.txt
@@ -51,14 +51,14 @@ OPTIONS
CONFIGURATION
-------------
-include::fmt-merge-msg-config.txt[]
+include::config/fmt-merge-msg.txt[]
merge.summary::
Synonym to `merge.log`; this is deprecated and will be removed in
the future.
-EXAMPLE
--------
+EXAMPLES
+--------
---------
$ git fetch origin master
diff --git a/en/git-for-each-ref.txt b/en/git-for-each-ref.txt
index 111e1be6f54f73f25ef6715a17410e461724519a..774cecc7ede787d22da5b656fe5299e4830d1d2e 100644
--- a/en/git-for-each-ref.txt
+++ b/en/git-for-each-ref.txt
@@ -10,8 +10,9 @@ SYNOPSIS
[verse]
'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
[(--sort=<key>)...] [--format=<format>] [<pattern>...]
- [--points-at <object>] [(--merged | --no-merged) [<object>]]
- [--contains [<object>]]
+ [--points-at=<object>]
+ (--merged[=<object>] | --no-merged[=<object>])
+ [--contains[=<object>]] [--no-contains[=<object>]]
DESCRIPTION
-----------
@@ -25,35 +26,41 @@ host language allowing their direct evaluation in that language.
OPTIONS
-------
-<count>::
+<pattern>...::
+ If one or more patterns are given, only refs are shown that
+ match against at least one pattern, either using fnmatch(3) or
+ literally, in the latter case matching completely or from the
+ beginning up to a slash.
+
+--count=<count>::
By default the command shows all refs that match
`<pattern>`. This option makes it stop after showing
that many refs.
-<key>::
+--sort=<key>::
A field name to sort on. Prefix `-` to sort in
descending order of the value. When unspecified,
`refname` is used. You may use the --sort=<key> option
multiple times, in which case the last key becomes the primary
key.
-<format>::
- A string that interpolates `%(fieldname)` from the
- object pointed at by a ref being shown. If `fieldname`
+--format=<format>::
+ A string that interpolates `%(fieldname)` from a ref being shown
+ and the object it points at. If `fieldname`
is prefixed with an asterisk (`*`) and the ref points
- at a tag object, the value for the field in the object
- tag refers is used. When unspecified, defaults to
+ at a tag object, use the value for the field in the object
+ which the tag object refers to (instead of the field in the tag object).
+ When unspecified, `<format>` defaults to
`%(objectname) SPC %(objecttype) TAB %(refname)`.
It also interpolates `%%` to `%`, and `%xx` where `xx`
are hex digits interpolates to character with hex code
`xx`; for example `%00` interpolates to `\0` (NUL),
`%09` to `\t` (TAB) and `%0a` to `\n` (LF).
-<pattern>...::
- If one or more patterns are given, only refs are shown that
- match against at least one pattern, either using fnmatch(3) or
- literally, in the latter case matching completely or from the
- beginning up to a slash.
+--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).
--shell::
--perl::
@@ -64,21 +71,27 @@ OPTIONS
the specified host language. This is meant to produce
a scriptlet that can directly be `eval`ed.
---points-at <object>::
+--points-at=<object>::
Only list refs which points at the given object.
---merged [<object>]::
+--merged[=<object>]::
Only list refs whose tips are reachable from the
- specified commit (HEAD if not specified).
+ specified commit (HEAD if not specified),
+ incompatible with `--no-merged`.
---no-merged [<object>]::
+--no-merged[=<object>]::
Only list refs whose tips are not reachable from the
- specified commit (HEAD if not specified).
+ specified commit (HEAD if not specified),
+ incompatible with `--merged`.
---contains [<object>]::
+--contains[=<object>]::
Only list refs which contain the specified commit (HEAD if not
specified).
+--no-contains[=<object>]::
+ Only list refs which don't contain the specified commit (HEAD
+ if not specified).
+
--ignore-case::
Sorting and filtering refs are case insensitive.
@@ -108,20 +121,25 @@ refname::
stripping with positive <N>, or it becomes the full refname if
stripping with negative <N>. Neither is an error.
+
-`strip` can be used as a synomym to `lstrip`.
+`strip` can be used as a synonym to `lstrip`.
objecttype::
The type of the object (`blob`, `tree`, `commit`, `tag`).
objectsize::
The size of the object (the same as 'git cat-file -s' reports).
-
+ Append `:disk` to get the size, in bytes, that the object takes up on
+ disk. See the note about on-disk sizes in the `CAVEATS` section below.
objectname::
The object name (aka SHA-1).
For a non-ambiguous abbreviation of the object name append `:short`.
For an abbreviation of the object name with desired length append
`:short=<length>`, where the minimum length is MINIMUM_ABBREV. The
length may be exceeded to ensure unique object names.
+deltabase::
+ This expands to the object name of the delta base for the
+ given object, if it is stored as a delta. Otherwise it
+ expands to the null object name (all zeroes).
upstream::
The name of a local ref which can be considered ``upstream''
@@ -132,26 +150,35 @@ upstream::
(behind), "<>" (ahead and behind), or "=" (in sync). `:track`
also prints "[gone]" whenever unknown upstream ref is
encountered. Append `:track,nobracket` to show tracking
- information without brackets (i.e "ahead N, behind M"). Has
- no effect if the ref does not have tracking information
- associated with it. All the options apart from `nobracket`
- are mutually exclusive, but if used together the last option
- is selected.
+ information without brackets (i.e "ahead N, behind M").
++
+For any remote-tracking branch `%(upstream)`, `%(upstream:remotename)`
+and `%(upstream:remoteref)` refer to the name of the remote and the
+name of the tracked remote ref, respectively. In other words, the
+remote-tracking branch can be updated explicitly and individually by
+using the refspec `%(upstream:remoteref):%(upstream)` to fetch from
+`%(upstream:remotename)`.
++
+Has no effect if the ref does not have tracking information associated
+with it. All the options apart from `nobracket` are mutually exclusive,
+but if used together the last option is selected.
push::
The name of a local ref which represents the `@{push}`
location for the displayed ref. Respects `:short`, `:lstrip`,
- `:rstrip`, `:track`, and `:trackshort` options as `upstream`
- does. Produces an empty string if no `@{push}` ref is
- configured.
+ `:rstrip`, `:track`, `:trackshort`, `:remotename`, and `:remoteref`
+ options as `upstream` does. Produces an empty string if no `@{push}`
+ ref is configured.
HEAD::
'*' if HEAD matches current ref (the checked out branch), ' '
otherwise.
color::
- Change output color. Followed by `:<colorname>`, where names
- are described in `color.branch.*`.
+ Change output color. Followed by `:<colorname>`, where color
+ names are described under Values in the "CONFIGURATION FILE"
+ section of linkgit:git-config[1]. For example,
+ `%(color:bold red)`.
align::
Left-, middle-, or right-align the content between
@@ -203,11 +230,15 @@ and `date` to extract the named component.
The complete message in a commit and tag object is `contents`.
Its first line is `contents:subject`, where subject is the concatenation
of all lines of the commit message up to the first blank line. The next
-line is 'contents:body', where body is all of the lines after the first
+line is `contents:body`, where body is all of the lines after the first
blank line. The optional GPG signature is `contents:signature`. The
first `N` lines of the message is obtained using `contents:lines=N`.
Additionally, the trailers as interpreted by linkgit:git-interpret-trailers[1]
-are obtained as 'contents:trailers'.
+are obtained as `trailers` (or by using the historical alias
+`contents:trailers`). Non-trailer lines from the trailer block can be omitted
+with `trailers:only`. Whitespace-continuations can be removed from trailers so
+that each trailer appears on a line by itself with its full content with
+`trailers:unfold`. Both can be used together as `trailers:unfold,only`.
For sorting purposes, fields with numeric values sort in numeric order
(`objectsize`, `authordate`, `committerdate`, `creatordate`, `taggerdate`).
@@ -335,6 +366,20 @@ This prints the authorname, if present.
git for-each-ref --format="%(refname)%(if)%(authorname)%(then) Authored by: %(authorname)%(end)"
------------
+CAVEATS
+-------
+
+Note that the sizes of objects on disk are reported accurately, but care
+should be taken in drawing conclusions about which refs or objects are
+responsible for disk usage. The size of a packed non-delta object may be
+much larger than the size of objects which delta against it, but the
+choice of which object is the base and which is the delta is arbitrary
+and is subject to change during a repack.
+
+Note also that multiple copies of an object may be present in the object
+database; in this case, it is undefined which copy's size or delta base
+will be reported.
+
SEE ALSO
--------
linkgit:git-show-ref[1]
diff --git a/en/git-format-patch.txt b/en/git-format-patch.txt
index f7a069bb9234850568d0870fa92ef25d0e1a19b5..1af85d404f5191c18a8c587df06e7c0620066236 100644
--- a/en/git-format-patch.txt
+++ b/en/git-format-patch.txt
@@ -23,6 +23,9 @@ SYNOPSIS
[(--reroll-count|-v) <n>]
[--to=<email>] [--cc=<email>]
[--[no-]cover-letter] [--quiet] [--notes[=<ref>]]
+ [--interdiff=<previous>]
+ [--range-diff=<previous> [--creation-factor=<percent>]]
+ [--progress]
[<common diff options>]
[ <since> | <revision range> ]
@@ -46,7 +49,7 @@ There are two ways to specify which commits to operate on.
The first rule takes precedence in the case of a single <commit>. To
apply the second rule, i.e., format everything since the beginning of
-history up until <commit>, use the '\--root' option: `git format-patch
+history up until <commit>, use the `--root` option: `git format-patch
--root <commit>`. If you want to format only <commit> itself, you
can do this with `git format-patch -1 <commit>`.
@@ -227,6 +230,38 @@ feeding the result to `git send-email`.
containing the branch description, shortlog and the overall diffstat. You can
fill in a description in the file before sending it out.
+--interdiff=<previous>::
+ As a reviewer aid, insert an interdiff into the cover letter,
+ or as commentary of the lone patch of a 1-patch series, showing
+ the differences between the previous version of the patch series and
+ the series currently being formatted. `previous` is a single revision
+ naming the tip of the previous series which shares a common base with
+ the series being formatted (for example `git format-patch
+ --cover-letter --interdiff=feature/v1 -3 feature/v2`).
+
+--range-diff=<previous>::
+ As a reviewer aid, insert a range-diff (see linkgit:git-range-diff[1])
+ into the cover letter, or as commentary of the lone patch of a
+ 1-patch series, showing the differences between the previous
+ version of the patch series and the series currently being formatted.
+ `previous` can be a single revision naming the tip of the previous
+ series if it shares a common base with the series being formatted (for
+ example `git format-patch --cover-letter --range-diff=feature/v1 -3
+ feature/v2`), or a revision range if the two versions of the series are
+ disjoint (for example `git format-patch --cover-letter
+ --range-diff=feature/v1~3..feature/v1 -3 feature/v2`).
++
+Note that diff options passed to the command affect how the primary
+product of `format-patch` is generated, and they are not passed to
+the underlying `range-diff` machinery used to generate the cover-letter
+material (this may change in the future).
+
+--creation-factor=<percent>::
+ Used with `--range-diff`, tweak the heuristic which matches up commits
+ between the previous and current series of patches by adjusting the
+ creation/deletion cost fudge factor. See linkgit:git-range-diff[1])
+ for details.
+
--notes[=<ref>]::
Append the notes (see linkgit:git-notes[1]) for the commit
after the three-dash line.
@@ -283,6 +318,9 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
range are always formatted as creation patches, independently
of this flag.
+--progress::
+ Show progress reports on stderr as patches are generated.
+
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each message,
@@ -466,9 +504,9 @@ Toggle it to make sure it is set to `false`. Also, search for
"mailnews.wraplength" and set the value to 0.
3. Disable the use of format=flowed:
-Edit..Preferences..Advanced..Config Editor. Search for
-"mailnews.send_plaintext_flowed".
-Toggle it to make sure it is set to `false`.
+ Edit..Preferences..Advanced..Config Editor. Search for
+ "mailnews.send_plaintext_flowed".
+ Toggle it to make sure it is set to `false`.
After that is done, you should be able to compose email as you
otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc),
@@ -557,7 +595,7 @@ series A, B, C, the history would be like:
................................................
With `git format-patch --base=P -3 C` (or variants thereof, e.g. with
-`--cover-letter` of using `Z..C` instead of `-3 C` to specify the
+`--cover-letter` or using `Z..C` instead of `-3 C` to specify the
range), the base tree information block is shown at the end of the
first message the command outputs (either the first patch, or the
cover letter), like this:
@@ -591,14 +629,14 @@ EXAMPLES
--------
* Extract commits between revisions R1 and R2, and apply them on top of
-the current branch using 'git am' to cherry-pick them:
+ the current branch using 'git am' to cherry-pick them:
+
------------
$ git format-patch -k --stdout R1..R2 | git am -3 -k
------------
* Extract all commits which are in the current branch but not in the
-origin branch:
+ origin branch:
+
------------
$ git format-patch origin
@@ -607,7 +645,7 @@ $ git format-patch origin
For each commit a separate file is created in the current directory.
* Extract all commits that lead to 'origin' since the inception of the
-project:
+ project:
+
------------
$ git format-patch --root origin
@@ -626,7 +664,7 @@ Note that non-Git "patch" programs won't understand renaming patches, so
use it only when you know the recipient uses Git to apply your patch.
* Extract three topmost commits from the current branch and format them
-as e-mailable patches:
+ as e-mailable patches:
+
------------
$ git format-patch -3
diff --git a/en/git-fsck.txt b/en/git-fsck.txt
index b9f060e3b207f981932957d8148dfcfcd912e33c..55950d9eea9edb5157352fa3e6316ef3507e99bf 100644
--- a/en/git-fsck.txt
+++ b/en/git-fsck.txt
@@ -110,6 +110,9 @@ Any corrupt objects you will have to find in backups or other archives
(i.e., you can just remove them and do an 'rsync' with some other site in
the hopes that somebody else has the object you have corrupted).
+If core.commitGraph is true, the commit-graph file will also be inspected
+using 'git commit-graph verify'. See linkgit:git-commit-graph[1].
+
Extracted Diagnostics
---------------------
@@ -137,9 +140,9 @@ dangling <type> <object>::
The <type> object <object>, is present in the database but never
'directly' used. A dangling commit could be a root node.
-sha1 mismatch <object>::
- The database has an object who's sha1 doesn't match the
- database value.
+hash mismatch <object>::
+ The database has an object whose hash doesn't match the
+ object database value.
This indicates a serious data integrity problem.
Environment Variables
diff --git a/en/git-gc.txt b/en/git-gc.txt
index 571b5a7e3c9dbc11aafc194b6e08dbbed5b2f7d3..a7442499f6d3985fa2ca57fa827d454b11479705 100644
--- a/en/git-gc.txt
+++ b/en/git-gc.txt
@@ -9,14 +9,16 @@ git-gc - Cleanup unnecessary files and optimize the local repository
SYNOPSIS
--------
[verse]
-'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force]
+'git gc' [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]
DESCRIPTION
-----------
Runs a number of housekeeping tasks within the current repository,
such as compressing file revisions (to reduce disk space and increase
-performance) and removing unreachable objects which may have been
-created from prior invocations of 'git add'.
+performance), removing unreachable objects which may have been
+created from prior invocations of 'git add', packing refs, pruning
+reflog, rerere metadata or stale working trees. May also update ancillary
+indexes such as the commit-graph.
Users are encouraged to run this task on a regular basis within
each repository to maintain good disk space utilization and good
@@ -45,20 +47,31 @@ OPTIONS
With this option, 'git gc' checks whether any housekeeping is
required; if not, it exits without performing any work.
Some git commands run `git gc --auto` after performing
- operations that could create many loose objects.
+ operations that could create many loose objects. Housekeeping
+ is required if there are too many loose objects or too many
+ packs in the repository.
+
-Housekeeping is required if there are too many loose objects or
-too many packs in the repository. If the number of loose objects
-exceeds the value of the `gc.auto` configuration variable, then
-all loose objects are combined into a single pack using
-`git repack -d -l`. Setting the value of `gc.auto` to 0
-disables automatic packing of loose objects.
+If the number of loose objects exceeds the value of the `gc.auto`
+configuration variable, then all loose objects are combined into a
+single pack using `git repack -d -l`. Setting the value of `gc.auto`
+to 0 disables automatic packing of loose objects.
+
If the number of packs exceeds the value of `gc.autoPackLimit`,
-then existing packs (except those marked with a `.keep` file)
+then existing packs (except those marked with a `.keep` file
+or over `gc.bigPackThreshold` limit)
are consolidated into a single pack by using the `-A` option of
-'git repack'. Setting `gc.autoPackLimit` to 0 disables
-automatic consolidation of packs.
+'git repack'.
+If the amount of memory is estimated not enough for `git repack` to
+run smoothly and `gc.bigPackThreshold` is not set, the largest
+pack will also be excluded (this is the equivalent of running `git gc`
+with `--keep-base-pack`).
+Setting `gc.autoPackLimit` to 0 disables automatic consolidation of
+packs.
++
+If houskeeping is required due to many loose objects or packs, all
+other housekeeping tasks (e.g. rerere, working trees, reflog...) will
+be performed as well.
+
--prune=<date>::
Prune loose objects older than date (default is 2 weeks ago,
@@ -78,7 +91,12 @@ automatic consolidation of packs.
Force `git gc` to run even if there may be another `git gc`
instance running on this repository.
-Configuration
+--keep-largest-pack::
+ All packs except the largest pack and those marked with a
+ `.keep` files are consolidated into a single pack. When this
+ option is used, `gc.bigPackThreshold` is ignored.
+
+CONFIGURATION
-------------
The optional configuration variable `gc.reflogExpire` can be
@@ -119,11 +137,15 @@ The optional configuration variable `gc.packRefs` determines if
it within all non-bare repos or it can be set to a boolean value.
This defaults to true.
+The optional configuration variable `gc.writeCommitGraph` determines if
+'git gc' should run 'git commit-graph write'. This can be set to a
+boolean value. This defaults to false.
+
The optional configuration variable `gc.aggressiveWindow` controls how
much time is spent optimizing the delta compression of the objects in
the repository when the --aggressive option is specified. The larger
the value, the more time is spent optimizing the delta compression. See
-the documentation for the --window' option in linkgit:git-repack[1] for
+the documentation for the --window option in linkgit:git-repack[1] for
more details. This defaults to 250.
Similarly, the optional configuration variable `gc.aggressiveDepth`
@@ -133,8 +155,12 @@ The optional configuration variable `gc.pruneExpire` controls how old
the unreferenced loose objects have to be before they are pruned. The
default is "2 weeks ago".
+Optional configuration variable `gc.worktreePruneExpire` controls how
+old a stale working tree should be before `git worktree prune` deletes
+it. Default is "3 months ago".
+
-Notes
+NOTES
-----
'git gc' tries very hard not to delete objects that are referenced
diff --git a/en/git-grep.txt b/en/git-grep.txt
index 71f32f35089241bc452cfdccdc6b3e9a30f95366..84fe236a8ee2fd47814c4c7ee854c47279921169 100644
--- a/en/git-grep.txt
+++ b/en/git-grep.txt
@@ -13,12 +13,12 @@ SYNOPSIS
[-v | --invert-match] [-h|-H] [--full-name]
[-E | --extended-regexp] [-G | --basic-regexp]
[-P | --perl-regexp]
- [-F | --fixed-strings] [-n | --line-number]
+ [-F | --fixed-strings] [-n | --line-number] [--column]
[-l | --files-with-matches] [-L | --files-without-match]
[(-O | --open-files-in-pager) [<pager>]]
[-z | --null]
- [-c | --count] [--all-match] [-q | --quiet]
- [--max-depth <depth>]
+ [ -o | --only-matching ] [-c | --count] [--all-match] [-q | --quiet]
+ [--max-depth <depth>] [--[no-]recursive]
[--color[=<when>] | --no-color]
[--break] [--heading] [-p | --show-function]
[-A <post-context>] [-B <pre-context>] [-C <context>]
@@ -44,6 +44,9 @@ CONFIGURATION
grep.lineNumber::
If set to true, enable `-n` option by default.
+grep.column::
+ If set to true, enable the `--column` option by default.
+
grep.patternType::
Set the default matching behavior. Using a value of 'basic', 'extended',
'fixed', or 'perl' will enable the `--basic-regexp`, `--extended-regexp`,
@@ -95,13 +98,6 @@ OPTIONS
<tree> option the prefix of all submodule output will be the name of
the parent project's <tree> object.
---parent-basename <basename>::
- For internal use only. In order to produce uniform output with the
- --recurse-submodules option, this option can be used to provide the
- basename of a parent's <tree> object to a submodule so the submodule
- can prefix its output with the parent's name rather than the SHA1 of
- the submodule.
-
-a::
--text::
Process binary files as if they were text.
@@ -123,11 +119,18 @@ OPTIONS
--max-depth <depth>::
For each <pathspec> given on command line, descend at most <depth>
- levels of directories. A negative value means no limit.
+ levels of directories. A value of -1 means no limit.
This option is ignored if <pathspec> contains active wildcards.
In other words if "a*" matches a directory named "a*",
"*" is matched literally so --max-depth is still effective.
+-r::
+--recursive::
+ Same as `--max-depth=-1`; this is the default.
+
+--no-recursive::
+ Same as `--max-depth=0`.
+
-w::
--word-regexp::
Match the pattern only at word boundary (either begin at the
@@ -161,8 +164,11 @@ OPTIONS
-P::
--perl-regexp::
- Use Perl-compatible regexp for patterns. Requires libpcre to be
- compiled in.
+ Use Perl-compatible regular expressions for patterns.
++
+Support for these types of regular expressions is an optional
+compile-time dependency. If Git wasn't compiled with support for them
+providing this option will cause it to die.
-F::
--fixed-strings::
@@ -173,6 +179,10 @@ OPTIONS
--line-number::
Prefix the line number to matching lines.
+--column::
+ Prefix the 1-indexed byte-offset of the first match from the start of the
+ matching line.
+
-l::
--files-with-matches::
--name-only::
@@ -198,6 +208,11 @@ OPTIONS
Output \0 instead of the character that normally follows a
file name.
+-o::
+--only-matching::
+ Print only the matched (non-empty) parts of a matching line, with each such
+ part on a separate output line.
+
-c::
--count::
Instead of showing every matched line, show the number of
@@ -293,8 +308,11 @@ OPTIONS
<pathspec>...::
If given, limit the search to paths matching at least one pattern.
Both leading paths match and glob(7) patterns are supported.
++
+For more details about the <pathspec> syntax, see the 'pathspec' entry
+in linkgit:gitglossary[7].
-Examples
+EXAMPLES
--------
`git grep 'time_t' -- '*.[ch]'`::
@@ -309,6 +327,9 @@ Examples
Looks for a line that has `NODE` or `Unexpected` in
files that have lines that match both.
+`git grep solution -- :^Documentation`::
+ Looks for `solution`, excluding files in `Documentation`.
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/en/git-help.txt b/en/git-help.txt
index 40d328a4b3e7e03720cbefc5100ee8e752f6a586..c318bf87e174f18798a2fcb0530bec05a34c4c92 100644
--- a/en/git-help.txt
+++ b/en/git-help.txt
@@ -8,7 +8,7 @@ git-help - Display help information about Git
SYNOPSIS
--------
[verse]
-'git help' [-a|--all] [-g|--guide]
+'git help' [-a|--all [--[no-]verbose]] [-g|--guide]
[-i|--info|-m|--man|-w|--web] [COMMAND|GUIDE]
DESCRIPTION
@@ -29,6 +29,10 @@ guide is brought up. The 'man' program is used by default for this
purpose, but this can be overridden by other options or configuration
variables.
+If an alias is given, git shows the definition of the alias on
+standard output. To get the manual page for the aliased command, use
+`git COMMAND --help`.
+
Note that `git --help ...` is identical to `git help ...` because the
former is internally converted into the latter.
@@ -43,6 +47,15 @@ OPTIONS
Prints all the available commands on the standard output. This
option overrides any given command or guide name.
+--verbose::
+ When used with `--all` print description for all recognized
+ commands. This is the default.
+
+-c::
+--config::
+ List all available configuration variables. This is a short
+ summary of the list in linkgit:git-config[1].
+
-g::
--guides::
Prints a list of useful guides on the standard output. This
@@ -105,9 +118,9 @@ format is chosen. The following values are currently supported:
* "man": use the 'man' program as usual,
* "woman": use 'emacsclient' to launch the "woman" mode in emacs
-(this only works starting with emacsclient versions 22),
+ (this only works starting with emacsclient versions 22),
* "konqueror": use 'kfmclient' to open the man page in a new konqueror
-tab (see 'Note about konqueror' below).
+ tab (see 'Note about konqueror' below).
Values for other tools can be used if there is a corresponding
`man.<tool>.cmd` configuration entry (see below).
diff --git a/en/git-http-fetch.txt b/en/git-http-fetch.txt
index 21a33d2c414e24eb779669f10beefde58db00f1c..666b042679f405fd1759b42a8d86aafb083e817c 100644
--- a/en/git-http-fetch.txt
+++ b/en/git-http-fetch.txt
@@ -15,8 +15,9 @@ DESCRIPTION
-----------
Downloads a remote Git repository via HTTP.
-*NOTE*: use of this command without -a is deprecated. The -a
-behaviour will become the default in a future release.
+This command always gets all objects. Historically, there were three options
+`-a`, `-c` and `-t` for choosing which objects to download. They are now
+silently ignored.
OPTIONS
-------
@@ -24,12 +25,8 @@ commit-id::
Either the hash or the filename under [URL]/refs/ to
pull.
--c::
- Get the commit objects.
--t::
- Get trees associated with the commit objects.
--a::
- Get all the objects.
+-a, -c, -t::
+ These options are ignored for historical reasons.
-v::
Report what is downloaded.
diff --git a/en/git-http-push.txt b/en/git-http-push.txt
index 2aceb6f26da2299d87afe6aeeaf54d18d1487488..ea03a4eeb0fd3124e784553f55c3dccac84a03c7 100644
--- a/en/git-http-push.txt
+++ b/en/git-http-push.txt
@@ -55,7 +55,7 @@ OPTIONS
The remote refs to update.
-Specifying the Refs
+SPECIFYING THE REFS
-------------------
A '<ref>' specification can be either a single pattern, or a pair
diff --git a/en/git-imap-send.txt b/en/git-imap-send.txt
index 5d1e4c80cd5d479a43c39ffb12b66a7302e754e7..65b53fcc47d6b93cd2a63309401c227cf899794f 100644
--- a/en/git-imap-send.txt
+++ b/en/git-imap-send.txt
@@ -57,50 +57,7 @@ to appropriate values.
Variables
~~~~~~~~~
-imap.folder::
- The folder to drop the mails into, which is typically the Drafts
- folder. For example: "INBOX.Drafts", "INBOX/Drafts" or
- "[Gmail]/Drafts". Required.
-
-imap.tunnel::
- Command used to setup a tunnel to the IMAP server through which
- commands will be piped instead of using a direct network connection
- to the server. Required when imap.host is not set.
-
-imap.host::
- A URL identifying the server. Use a `imap://` prefix for non-secure
- connections and a `imaps://` prefix for secure connections.
- Ignored when imap.tunnel is set, but required otherwise.
-
-imap.user::
- The username to use when logging in to the server.
-
-imap.pass::
- The password to use when logging in to the server.
-
-imap.port::
- An integer port number to connect to on the server.
- Defaults to 143 for imap:// hosts and 993 for imaps:// hosts.
- Ignored when imap.tunnel is set.
-
-imap.sslverify::
- A boolean to enable/disable verification of the server certificate
- used by the SSL/TLS connection. Default is `true`. Ignored when
- imap.tunnel is set.
-
-imap.preformattedHTML::
- A boolean to enable/disable the use of html encoding when sending
- a patch. An html encoded patch will be bracketed with <pre>
- and have a content type of text/html. Ironically, enabling this
- option causes Thunderbird to send the patch as a plain/text,
- format=fixed email. Default is `false`.
-
-imap.authMethod::
- Specify authenticate method for authentication with IMAP server.
- If Git was built with the NO_CURL option, or if your curl version is older
- than 7.34.0, or if you're running git-imap-send with the `--no-curl`
- option, the only supported method is 'CRAM-MD5'. If this is not set
- then 'git imap-send' uses the basic IMAP plaintext LOGIN command.
+include::config/imap.txt[]
Examples
~~~~~~~~
@@ -136,8 +93,8 @@ Using direct mode with SSL:
.........................
-EXAMPLE
--------
+EXAMPLES
+--------
To submit patches using GMail's IMAP interface, first, edit your ~/.gitconfig
to specify your account settings:
diff --git a/en/git-index-pack.txt b/en/git-index-pack.txt
index 1b4b65d6657b003079e0407d1da8d8c239933267..d5b7560bfe2d51370c313ee006a9f0ed4388eda4 100644
--- a/en/git-index-pack.txt
+++ b/en/git-index-pack.txt
@@ -77,6 +77,9 @@ OPTIONS
--check-self-contained-and-connected::
Die if the pack contains broken links. For internal use only.
+--fsck-objects::
+ Die if the pack contains broken objects. For internal use only.
+
--threads=<n>::
Specifies the number of threads to spawn when resolving
deltas. This requires that index-pack be compiled with
@@ -90,8 +93,8 @@ OPTIONS
--max-input-size=<size>::
Die, if the pack is larger than <size>.
-Note
-----
+NOTES
+-----
Once the index has been created, the list of object names is sorted
and the SHA-1 hash of that list is printed to stdout. If --stdin was
diff --git a/en/git-init.txt b/en/git-init.txt
index 3c5a67fb9671f8c65e0830222c63bb5035a05c30..32880aafb0c55ce29f35490fd734587c38095066 100644
--- a/en/git-init.txt
+++ b/en/git-init.txt
@@ -38,8 +38,6 @@ the repository to another place if --separate-git-dir is given).
OPTIONS
-------
---
-
-q::
--quiet::
@@ -111,8 +109,6 @@ into it.
If you provide a 'directory', the command is run inside it. If this directory
does not exist, it will be created.
---
-
TEMPLATE DIRECTORY
------------------
@@ -132,7 +128,7 @@ The template directory will be one of the following (in order):
The default template directory includes some directory structure, suggested
"exclude patterns" (see linkgit:gitignore[5]), and sample hook files.
-The sample hooks are all disabled by default, To enable one of the
+The sample hooks are all disabled by default. To enable one of the
sample hooks rename it by removing its `.sample` suffix.
See linkgit:githooks[5] for more general info on hook execution.
diff --git a/en/git-instaweb.txt b/en/git-instaweb.txt
index e8ecdbf927ba5e7af79d3852a9a939c10052e45f..a54fe4401bd1a21c6bd133745ab8864882ca73d4 100644
--- a/en/git-instaweb.txt
+++ b/en/git-instaweb.txt
@@ -29,7 +29,8 @@ OPTIONS
The HTTP daemon command-line that will be executed.
Command-line options may be specified here, and the
configuration file will be added at the end of the command-line.
- Currently apache2, lighttpd, mongoose, plackup and webrick are supported.
+ Currently apache2, lighttpd, mongoose, plackup, python and
+ webrick are supported.
(Default: lighttpd)
-m::
diff --git a/en/git-interpret-trailers.txt b/en/git-interpret-trailers.txt
index 09074c75a46b148485f836e1e10d7590f98d54b6..a5e8b36f62bcf5eeedfb5a04ac852c476d9f43f3 100644
--- a/en/git-interpret-trailers.txt
+++ b/en/git-interpret-trailers.txt
@@ -3,24 +3,27 @@ git-interpret-trailers(1)
NAME
----
-git-interpret-trailers - help add structured information into commit messages
+git-interpret-trailers - add or parse structured information in commit messages
SYNOPSIS
--------
[verse]
-'git interpret-trailers' [--in-place] [--trim-empty] [(--trailer <token>[(=|:)<value>])...] [<file>...]
+'git interpret-trailers' [<options>] [(--trailer <token>[(=|:)<value>])...] [<file>...]
+'git interpret-trailers' [<options>] [--parse] [<file>...]
DESCRIPTION
-----------
-Help adding 'trailers' lines, that look similar to RFC 822 e-mail
+Help parsing or adding 'trailers' lines, that look similar to RFC 822 e-mail
headers, at the end of the otherwise free-form part of a commit
message.
This command reads some patches or commit messages from either the
-<file> arguments or the standard input if no <file> is specified. Then
-this command applies the arguments passed using the `--trailer`
-option, if any, to the commit message part of each input file. The
-result is emitted on the standard output.
+<file> arguments or the standard input if no <file> is specified. If
+`--parse` is specified, the output consists of the parsed trailers.
+
+Otherwise, this command applies the arguments passed using the
+`--trailer` option, if any, to the commit message part of each input
+file. The result is emitted on the standard output.
Some configuration variables control the way the `--trailer` arguments
are applied to each commit message and the way any existing trailer in
@@ -48,13 +51,14 @@ with only spaces at the end of the commit message part, one blank line
will be added before the new trailer.
Existing trailers are extracted from the input message by looking for
-a group of one or more lines that (i) are all trailers, or (ii) contains at
+a group of one or more lines that (i) is all trailers, or (ii) contains at
least one Git-generated or user-configured trailer and consists of at
least 25% trailers.
The group must be preceded by one or more empty (or whitespace-only) lines.
The group must either be at the end of the message or be the last
-non-whitespace lines before a line that starts with '---'. Such three
-minus signs start the patch part of the message.
+non-whitespace lines before a line that starts with '---' (followed by a
+space or the end of the line). Such three minus signs start the patch
+part of the message. See also `--no-divider` below.
When reading trailers, there can be whitespaces after the
token, the separator and the value. There can also be whitespaces
@@ -80,6 +84,53 @@ OPTIONS
trailer to the input messages. See the description of this
command.
+--where <placement>::
+--no-where::
+ Specify where all new trailers will be added. A setting
+ provided with '--where' overrides all configuration variables
+ and applies to all '--trailer' options until the next occurrence of
+ '--where' or '--no-where'. Possible values are `after`, `before`,
+ `end` or `start`.
+
+--if-exists <action>::
+--no-if-exists::
+ Specify what action will be performed when there is already at
+ least one trailer with the same <token> in the message. A setting
+ provided with '--if-exists' overrides all configuration variables
+ and applies to all '--trailer' options until the next occurrence of
+ '--if-exists' or '--no-if-exists'. Possible actions are `addIfDifferent`,
+ `addIfDifferentNeighbor`, `add`, `replace` and `doNothing`.
+
+--if-missing <action>::
+--no-if-missing::
+ Specify what action will be performed when there is no other
+ trailer with the same <token> in the message. A setting
+ provided with '--if-missing' overrides all configuration variables
+ and applies to all '--trailer' options until the next occurrence of
+ '--if-missing' or '--no-if-missing'. Possible actions are `doNothing`
+ or `add`.
+
+--only-trailers::
+ Output only the trailers, not any other parts of the input.
+
+--only-input::
+ Output only trailers that exist in the input; do not add any
+ from the command-line or by following configured `trailer.*`
+ rules.
+
+--unfold::
+ Remove any whitespace-continuation in trailers, so that each
+ trailer appears on a line by itself with its full content.
+
+--parse::
+ A convenience alias for `--only-trailers --only-input
+ --unfold`.
+
+--no-divider::
+ Do not treat `---` as the end of the commit message. Use this
+ when you know your input contains just the commit message itself
+ (and not an email or the output of `git format-patch`).
+
CONFIGURATION VARIABLES
-----------------------
@@ -123,7 +174,7 @@ trailer.ifexists::
same <token> in the message.
+
The valid values for this option are: `addIfDifferentNeighbor` (this
-is the default), `addIfDifferent`, `add`, `overwrite` or `doNothing`.
+is the default), `addIfDifferent`, `add`, `replace` or `doNothing`.
+
With `addIfDifferentNeighbor`, a new trailer will be added only if no
trailer with the same (<token>, <value>) pair is above or below the line
@@ -170,8 +221,8 @@ trailer.<token>.where::
configuration variable and it overrides what is specified by
that option for trailers with the specified <token>.
-trailer.<token>.ifexist::
- This option takes the same values as the 'trailer.ifexist'
+trailer.<token>.ifexists::
+ This option takes the same values as the 'trailer.ifexists'
configuration variable and it overrides what is specified by
that option for trailers with the specified <token>.
diff --git a/en/git-log.txt b/en/git-log.txt
index 32246fdb007e9b25f414cff092b9bf0426c55d15..b02e922dc33d248493df4bf6e1bb42f342e38daa 100644
--- a/en/git-log.txt
+++ b/en/git-log.txt
@@ -9,7 +9,7 @@ git-log - Show commit logs
SYNOPSIS
--------
[verse]
-'git log' [<options>] [<revision range>] [[\--] <path>...]
+'git log' [<options>] [<revision range>] [[--] <path>...]
DESCRIPTION
-----------
@@ -38,6 +38,13 @@ OPTIONS
are shown as if 'short' were given, otherwise no ref names are
shown. The default option is 'short'.
+--decorate-refs=<pattern>::
+--decorate-refs-exclude=<pattern>::
+ If no `--decorate-refs` is given, pretend as if all refs were
+ included. For each candidate, do not use it for decoration if it
+ matches any patterns given to `--decorate-refs-exclude` or if it
+ doesn't match any of the patterns given to `--decorate-refs`.
+
--source::
Print out the ref name given on the command line by which each
commit was reached.
@@ -83,13 +90,13 @@ include::line-range-format.txt[]
ways to spell <revision range>, see the 'Specifying Ranges'
section of linkgit:gitrevisions[7].
-[\--] <path>...::
+[--] <path>...::
Show only commits that are enough to explain how the files
that match the specified paths came to be. See 'History
Simplification' below for details and other simplification
modes.
+
-Paths may need to be prefixed with ``\-- '' to separate them from
+Paths may need to be prefixed with `--` to separate them from
options or the revision range, when confusion arises.
include::rev-list-options.txt[]
@@ -118,7 +125,7 @@ EXAMPLES
`git log --since="2 weeks ago" -- gitk`::
Show the changes during the last two weeks to the file 'gitk'.
- The ``--'' is necessary to avoid confusion with the *branch* named
+ The `--` is necessary to avoid confusion with the *branch* named
'gitk'
`git log --name-status release..test`::
@@ -185,6 +192,10 @@ log.date::
Default format for human-readable dates. (Compare the
`--date` option.) Defaults to "default", which means to write
dates like `Sat May 8 19:35:34 2010 -0500`.
++
+If the format is set to "auto:foo" and the pager is in use, format
+"foo" will be the used for the date format. Otherwise "default" will
+be used.
log.follow::
If `true`, `git log` will act as if the `--follow` option was used when
diff --git a/en/git-ls-files.txt b/en/git-ls-files.txt
index 1cab703f73611260845ef5e9926fe377e729b934..5298f1bc3052f47e390eee780efe665083744309 100644
--- a/en/git-ls-files.txt
+++ b/en/git-ls-files.txt
@@ -9,7 +9,7 @@ git-ls-files - Show information about files in the index and the working tree
SYNOPSIS
--------
[verse]
-'git ls-files' [-z] [-t] [-v]
+'git ls-files' [-z] [-t] [-v] [-f]
(--[cached|deleted|others|ignored|stage|unmerged|killed|modified])*
(-[c|d|o|i|s|u|k|m])*
[--eol]
@@ -53,11 +53,12 @@ OPTIONS
Show only ignored files in the output. When showing files in the
index, print only those matched by an exclude pattern. When
showing "other" files, show only those matched by an exclude
- pattern.
+ pattern. Standard ignore rules are not automatically activated,
+ therefore at least one of the `--exclude*` options is required.
-s::
--stage::
- Show staged contents' object name, mode bits and stage number in the output.
+ Show staged contents' mode bits, object name and stage number in the output.
--directory::
If a whole directory is classified as "other", show just its
@@ -133,6 +134,11 @@ a space) at the start of each line:
that are marked as 'assume unchanged' (see
linkgit:git-update-index[1]).
+-f::
+ Similar to `-t`, but use lowercase letters for files
+ that are marked as 'fsmonitor valid' (see
+ linkgit:git-update-index[1]).
+
--full-name::
When run from a subdirectory, the command usually
outputs paths relative to the current directory. This
@@ -178,7 +184,7 @@ followed by the ("attr/<eolattr>").
Files to show. If no files are given all files which match the other
specified criteria are shown.
-Output
+OUTPUT
------
'git ls-files' just outputs the filenames unless `--stage` is specified in
which case it outputs:
@@ -203,7 +209,7 @@ quoted as explained for the configuration variable `core.quotePath`
verbatim and the line is terminated by a NUL byte.
-Exclude Patterns
+EXCLUDE PATTERNS
----------------
'git ls-files' can use a list of "exclude patterns" when
diff --git a/en/git-ls-remote.txt b/en/git-ls-remote.txt
index 5f2628c8f86a65b0bfe8e29995fa2176927a30f0..b9fd3770a6ce19c341c421e07b68985d89d94df5 100644
--- a/en/git-ls-remote.txt
+++ b/en/git-ls-remote.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git ls-remote' [--heads] [--tags] [--refs] [--upload-pack=<exec>]
- [-q | --quiet] [--exit-code] [--get-url]
+ [-q | --quiet] [--exit-code] [--get-url] [--sort=<key>]
[--symref] [<repository> [<refs>...]]
DESCRIPTION
@@ -60,6 +60,24 @@ OPTIONS
upload-pack only shows the symref HEAD, so it will be the only
one shown by ls-remote.
+--sort=<key>::
+ Sort based on the key given. Prefix `-` to sort in descending order
+ of the value. 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.
+ See linkgit:git-for-each-ref[1] for more sort options, but be aware
+ keys like `committerdate` that require access to the objects
+ themselves will not work for refs whose objects have not yet been
+ fetched from the remote, and will give a `missing object` error.
+
+-o <option>::
+--server-option=<option>::
+ Transmit the given string to the server when communicating using
+ protocol version 2. The given string must not contain a NUL or LF
+ character.
+ When multiple `--server-option=<option>` are given, they are all
+ sent to the other side in the order listed on the command line.
+
<repository>::
The "remote" repository to query. This parameter can be
either a URL or the name of a remote (see the GIT URLS and
@@ -90,6 +108,10 @@ EXAMPLES
c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
+SEE ALSO
+--------
+linkgit:git-check-ref-format[1].
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/en/git-merge-base.txt b/en/git-merge-base.txt
index b968b64c380b4fbe2663da42355fc9e8fdd24679..9f07f4f6ed7f5036578f1cabb788f900247761c5 100644
--- a/en/git-merge-base.txt
+++ b/en/git-merge-base.txt
@@ -154,23 +154,71 @@ topic origin/master`, the history of remote-tracking branch
`origin/master` may have been rewound and rebuilt, leading to a
history of this shape:
- o---B1
+ o---B2
/
- ---o---o---B2--o---o---o---B (origin/master)
+ ---o---o---B1--o---o---o---B (origin/master)
\
- B3
+ B0
\
- Derived (topic)
+ D0---D1---D (topic)
-where `origin/master` used to point at commits B3, B2, B1 and now it
+where `origin/master` used to point at commits B0, B1, B2 and now it
points at B, and your `topic` branch was started on top of it back
-when `origin/master` was at B3. This mode uses the reflog of
-`origin/master` to find B3 as the fork point, so that the `topic`
-can be rebased on top of the updated `origin/master` by:
+when `origin/master` was at B0, and you built three commits, D0, D1,
+and D, on top of it. Imagine that you now want to rebase the work
+you did on the topic on top of the updated origin/master.
+
+In such a case, `git merge-base origin/master topic` would return the
+parent of B0 in the above picture, but B0^..D is *not* the range of
+commits you would want to replay on top of B (it includes B0, which
+is not what you wrote; it is a commit the other side discarded when
+it moved its tip from B0 to B1).
+
+`git merge-base --fork-point origin/master topic` is designed to
+help in such a case. It takes not only B but also B0, B1, and B2
+(i.e. old tips of the remote-tracking branches your repository's
+reflog knows about) into account to see on which commit your topic
+branch was built and finds B0, allowing you to replay only the
+commits on your topic, excluding the commits the other side later
+discarded.
+
+Hence
$ fork_point=$(git merge-base --fork-point origin/master topic)
+
+will find B0, and
+
$ git rebase --onto origin/master $fork_point topic
+will replay D0, D1 and D on top of B to create a new history of this
+shape:
+
+ o---B2
+ /
+ ---o---o---B1--o---o---o---B (origin/master)
+ \ \
+ B0 D0'--D1'--D' (topic - updated)
+ \
+ D0---D1---D (topic - old)
+
+A caveat is that older reflog entries in your repository may be
+expired by `git gc`. If B0 no longer appears in the reflog of the
+remote-tracking branch `origin/master`, the `--fork-point` mode
+obviously cannot find it and fails, avoiding to give a random and
+useless result (such as the parent of B0, like the same command
+without the `--fork-point` option gives).
+
+Also, the remote-tracking branch you use the `--fork-point` mode
+with must be the one your topic forked from its tip. If you forked
+from an older commit than the tip, this mode would not find the fork
+point (imagine in the above sample history B0 did not exist,
+origin/master started at B1, moved to B2 and then B, and you forked
+your topic at origin/master^ when origin/master was B1; the shape of
+the history would be the same as above, without B0, and the parent
+of B1 is what `git merge-base origin/master topic` correctly finds,
+but the `--fork-point` mode will not, because it is not one of the
+commits that used to be at the tip of origin/master).
+
See also
--------
diff --git a/en/git-merge.txt b/en/git-merge.txt
index ca3c27b88a4ea0dde17ed2e7f260ca6158a50073..4cc86469f3dd45564b40b327d1b39f2bb213bb98 100644
--- a/en/git-merge.txt
+++ b/en/git-merge.txt
@@ -12,8 +12,7 @@ SYNOPSIS
'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
[-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
[--[no-]allow-unrelated-histories]
- [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]
-'git merge' <msg> HEAD <commit>...
+ [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [<commit>...]
'git merge' --abort
'git merge' --continue
@@ -46,11 +45,7 @@ a log message from the user describing the changes.
D---E---F---G---H master
------------
-The second syntax (<msg> `HEAD` <commit>...) is supported for
-historical reasons. Do not use it from the command line or in
-new scripts. It is the same as `git merge -m <msg> <commit>...`.
-
-The third syntax ("`git merge --abort`") can only be run after the
+The second syntax ("`git merge --abort`") can only be run after the
merge has resulted in conflicts. 'git merge --abort' will abort the
merge process and try to reconstruct the pre-merge state. However,
if there were uncommitted changes when the merge started (and
@@ -62,19 +57,13 @@ reconstruct the original (pre-merge) changes. Therefore:
discouraged: while possible, it may leave you in a state that is hard to
back out of in the case of a conflict.
-The fourth syntax ("`git merge --continue`") can only be run after the
+The third syntax ("`git merge --continue`") can only be run after the
merge has resulted in conflicts.
OPTIONS
-------
include::merge-options.txt[]
--S[<keyid>]::
---gpg-sign[=<keyid>]::
- GPG-sign the resulting merge commit. The `keyid` argument is
- optional and defaults to the committer identity; if specified,
- it must be stuck to the option without a space.
-
-m <msg>::
Set the commit message to be used for the merge commit (in
case one is created).
@@ -86,6 +75,14 @@ The 'git fmt-merge-msg' command can be
used to give a good default for automated 'git merge'
invocations. The automated message can include the branch description.
+-F <file>::
+--file=<file>::
+ Read the commit message to be used for the merge commit (in
+ case one is created).
++
+If `--log` is specified, a shortlog of the commits being merged
+will be appended to the specified message.
+
--[no-]rerere-autoupdate::
Allow the rerere mechanism to update the index with the
result of auto-conflict resolution if possible.
@@ -133,12 +130,12 @@ merge' may need to update.
To avoid recording unrelated changes in the merge commit,
'git pull' and 'git merge' will also abort if there are any changes
-registered in the index relative to the `HEAD` commit. (One
-exception is when the changed index entries are in the state that
-would result from the merge already.)
+registered in the index relative to the `HEAD` commit. (Special
+narrow exceptions to this rule may exist depending on which merge
+strategy is in use, but generally, the index must match HEAD.)
If all named commits are already ancestors of `HEAD`, 'git merge'
-will exit early with the message "Already up-to-date."
+will exit early with the message "Already up to date."
FAST-FORWARD MERGE
------------------
@@ -285,7 +282,10 @@ After seeing a conflict, you can do two things:
* Resolve the conflicts. Git will mark the conflicts in
the working tree. Edit the files into shape and
- 'git add' them to the index. Use 'git commit' to seal the deal.
+ 'git add' them to the index. Use 'git commit' or
+ 'git merge --continue' to seal the deal. The latter command
+ checks whether there is a (interrupted) merge in progress
+ before calling 'git commit'.
You can work through the conflict with a number of tools:
@@ -342,7 +342,7 @@ include::merge-strategies.txt[]
CONFIGURATION
-------------
-include::merge-config.txt[]
+include::config/merge.txt[]
branch.<name>.mergeOptions::
Sets default options for merging into branch <name>. The syntax and
diff --git a/en/git-mergetool.txt b/en/git-mergetool.txt
index 3622d66488c7de057d32e02cd4cfd21704500822..0c7975a0507a35f9624516f0844ad11cd5141d50 100644
--- a/en/git-mergetool.txt
+++ b/en/git-mergetool.txt
@@ -79,6 +79,17 @@ success of the resolution after the custom tool has exited.
Prompt before each invocation of the merge resolution program
to give the user a chance to skip the path.
+-g::
+--gui::
+ When 'git-mergetool' is invoked with the `-g` or `--gui` option
+ the default merge tool will be read from the configured
+ `merge.guitool` variable instead of `merge.tool`.
+
+--no-gui::
+ This overrides a previous `-g` or `--gui` setting and reads the
+ default merge tool will be read from the configured `merge.tool`
+ variable.
+
-O<orderfile>::
Process files in the order specified in the
<orderfile>, which has one shell glob pattern per line.
diff --git a/en/git-mktree.txt b/en/git-mktree.txt
index c3616e7711aef80ee7e2bd3bb90ea5cee7dd1d4b..27fe2b32e10b2f0c92315483ac4a5e8a9722d3db 100644
--- a/en/git-mktree.txt
+++ b/en/git-mktree.txt
@@ -14,7 +14,7 @@ SYNOPSIS
DESCRIPTION
-----------
Reads standard input in non-recursive `ls-tree` output format, and creates
-a tree object. The order of the tree entries is normalised by mktree so
+a tree object. The order of the tree entries is normalized by mktree so
pre-sorting the input is not required. The object name of the tree object
built is written to the standard output.
diff --git a/en/git-name-rev.txt b/en/git-name-rev.txt
index e8e68f528cf2fa5705e7cedce8d3d807fa20057d..5cb0eb0855fefe582721baeb3295beb610a74891 100644
--- a/en/git-name-rev.txt
+++ b/en/git-name-rev.txt
@@ -61,8 +61,8 @@ OPTIONS
--always::
Show uniquely abbreviated commit object as fallback.
-EXAMPLE
--------
+EXAMPLES
+--------
Given a commit, find out where it is relative to the local refs. Say somebody
wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
diff --git a/en/git-notes.txt b/en/git-notes.txt
index be7db3048d4776200c6ed8781b25ffccb68a41eb..df2b64dbb618e3cf7c538798f5f18ebc41e7eff6 100644
--- a/en/git-notes.txt
+++ b/en/git-notes.txt
@@ -18,7 +18,7 @@ SYNOPSIS
'git notes' merge --commit [-v | -q]
'git notes' merge --abort [-v | -q]
'git notes' remove [--ignore-missing] [--stdin] [<object>...]
-'git notes' prune [-n | -v]
+'git notes' prune [-n] [-v]
'git notes' get-ref
@@ -171,7 +171,7 @@ OPTIONS
object that does not have notes attached to it.
--stdin::
- Also read the object names to remove notes from from the standard
+ Also read the object names to remove notes from the standard
input (there is no reason you cannot combine this with object
names from the command line).
@@ -199,7 +199,7 @@ OPTIONS
.git/NOTES_MERGE_REF symref is updated to the resulting commit.
--abort::
- Abort/reset a in-progress 'git notes merge', i.e. a notes merge
+ Abort/reset an in-progress 'git notes merge', i.e. a notes merge
with conflicts. This simply removes all files related to the
notes merge.
diff --git a/en/git-p4.txt b/en/git-p4.txt
index 7436c64a95616d84af9922958e4ccacd0c28519a..3494a1db3ebf4991ed05011a8f4035807db7a9f6 100644
--- a/en/git-p4.txt
+++ b/en/git-p4.txt
@@ -29,8 +29,8 @@ Submit Git changes back to p4 using 'git p4 submit'. The command
the updated p4 remote branch.
-EXAMPLE
--------
+EXAMPLES
+--------
* Clone a repository:
+
------------
@@ -71,12 +71,12 @@ $ git p4 clone //depot/path/project
------------
This:
-1. Creates an empty Git repository in a subdirectory called 'project'.
+1. Creates an empty Git repository in a subdirectory called 'project'.
+
-2. Imports the full contents of the head revision from the given p4
-depot path into a single commit in the Git branch 'refs/remotes/p4/master'.
+2. Imports the full contents of the head revision from the given p4
+ depot path into a single commit in the Git branch 'refs/remotes/p4/master'.
+
-3. Creates a local branch, 'master' from this remote and checks it out.
+3. Creates a local branch, 'master' from this remote and checks it out.
To reproduce the entire p4 history in Git, use the '@all' modifier on
the depot path:
@@ -149,6 +149,12 @@ To specify a branch other than the current one, use:
$ git p4 submit topicbranch
------------
+To specify a single commit or a range of commits, use:
+------------
+$ git p4 submit --commit <sha1>
+$ git p4 submit --commit <sha1..sha1>
+------------
+
The upstream reference is generally 'refs/remotes/p4/master', but can
be overridden using the `--origin=` command-line option.
@@ -157,6 +163,37 @@ The p4 changes will be created as the user invoking 'git p4 submit'. The
according to the author of the Git commit. This option requires admin
privileges in p4, which can be granted using 'p4 protect'.
+To shelve changes instead of submitting, use `--shelve` and `--update-shelve`:
+
+----
+$ git p4 submit --shelve
+$ git p4 submit --update-shelve 1234 --update-shelve 2345
+----
+
+
+Unshelve
+~~~~~~~~
+Unshelving will take a shelved P4 changelist, and produce the equivalent git commit
+in the branch refs/remotes/p4-unshelved/<changelist>.
+
+The git commit is created relative to the current origin revision (HEAD by default).
+A parent commit is created based on the origin, and then the unshelve commit is
+created based on that.
+
+The origin revision can be changed with the "--origin" option.
+
+If the target branch in refs/remotes/p4-unshelved already exists, the old one will
+be renamed.
+
+----
+$ git p4 sync
+$ git p4 unshelve 12345
+$ git show p4-unshelved/12345
+<submit more changes via p4 to the same files>
+$ git p4 unshelve 12345
+<refuses to unshelve until git is in sync with p4 again>
+
+----
OPTIONS
-------
@@ -310,7 +347,7 @@ These options can be used to modify 'git p4 submit' behavior.
--update-shelve CHANGELIST::
Update an existing shelved changelist with this commit. Implies
- --shelve.
+ --shelve. Repeat for multiple shelved changelists.
--conflict=(ask|skip|quit)::
Conflicts can occur when applying a commit to p4. When this
@@ -324,6 +361,27 @@ These options can be used to modify 'git p4 submit' behavior.
p4/master. See the "Sync options" section above for more
information.
+--commit <sha1>|<sha1..sha1>::
+ Submit only the specified commit or range of commits, instead of the full
+ list of changes that are in the current Git branch.
+
+--disable-rebase::
+ Disable the automatic rebase after all commits have been successfully
+ submitted. Can also be set with git-p4.disableRebase.
+
+--disable-p4sync::
+ Disable the automatic sync of p4/master from Perforce after commits have
+ been submitted. Implies --disable-rebase. Can also be set with
+ git-p4.disableP4Sync. Sync with origin/master still goes ahead if possible.
+
+Hook for submit
+~~~~~~~~~~~~~~~
+The `p4-pre-submit` hook is executed if it exists and is executable.
+The hook takes no parameters and nothing from standard input. Exiting with
+non-zero status from this script prevents `git-p4 submit` from launching.
+
+One usage scenario is to run unit tests in the hook.
+
Rebase options
~~~~~~~~~~~~~~
These options can be used to modify 'git p4 rebase' behavior.
@@ -331,6 +389,13 @@ These options can be used to modify 'git p4 rebase' behavior.
--import-labels::
Import p4 labels.
+Unshelve options
+~~~~~~~~~~~~~~~~
+
+--origin::
+ Sets the git refspec against which the shelved P4 changelist is compared.
+ Defaults to p4/master.
+
DEPOT PATH SYNTAX
-----------------
The p4 depot path argument to 'git p4 sync' and 'git p4 clone' can
@@ -386,7 +451,7 @@ dedicating a client spec just for 'git p4'.
The name of the client can be given to 'git p4' in multiple ways. The
variable 'git-p4.client' takes precedence if it exists. Otherwise,
normal p4 mechanisms of determining the client are used: environment
-variable P4CLIENT, a file referenced by P4CONFIG, or the local host name.
+variable `P4CLIENT`, a file referenced by `P4CONFIG`, or the local host name.
BRANCH DETECTION
@@ -455,22 +520,22 @@ General variables
~~~~~~~~~~~~~~~~~
git-p4.user::
User specified as an option to all p4 commands, with '-u <user>'.
- The environment variable 'P4USER' can be used instead.
+ The environment variable `P4USER` can be used instead.
git-p4.password::
Password specified as an option to all p4 commands, with
'-P <password>'.
- The environment variable 'P4PASS' can be used instead.
+ The environment variable `P4PASS` can be used instead.
git-p4.port::
Port specified as an option to all p4 commands, with
'-p <port>'.
- The environment variable 'P4PORT' can be used instead.
+ The environment variable `P4PORT` can be used instead.
git-p4.host::
Host specified as an option to all p4 commands, with
'-h <host>'.
- The environment variable 'P4HOST' can be used instead.
+ The environment variable `P4HOST` can be used instead.
git-p4.client::
Client specified as an option to all p4 commands, with
@@ -638,6 +703,12 @@ git-p4.conflict::
Specify submit behavior when a conflict with p4 is found, as per
--conflict. The default behavior is 'ask'.
+git-p4.disableRebase::
+ Do not rebase the tree against p4/master following a submit.
+
+git-p4.disableP4Sync::
+ Do not sync p4/master with Perforce following a submit. Implies git-p4.disableRebase.
+
IMPLEMENTATION DETAILS
----------------------
* Changesets from p4 are imported using Git fast-import.
diff --git a/en/git-pack-objects.txt b/en/git-pack-objects.txt
index 8973510a41c1e31319dad85d4987b3f0dfd7d8ca..e45f3e680d3632c8122db01b2a51cc3971c27922 100644
--- a/en/git-pack-objects.txt
+++ b/en/git-pack-objects.txt
@@ -12,14 +12,16 @@ SYNOPSIS
'git pack-objects' [-q | --progress | --all-progress] [--all-progress-implied]
[--no-reuse-delta] [--delta-base-offset] [--non-empty]
[--local] [--incremental] [--window=<n>] [--depth=<n>]
- [--revs [--unpacked | --all]] [--stdout | base-name]
- [--shallow] [--keep-true-parents] < object-list
+ [--revs [--unpacked | --all]] [--keep-pack=<pack-name>]
+ [--stdout [--filter=<filter-spec>] | base-name]
+ [--shallow] [--keep-true-parents] [--sparse] < object-list
DESCRIPTION
-----------
-Reads list of objects from the standard input, and writes a packed
-archive with specified base-name, or to the standard output.
+Reads list of objects from the standard input, and writes either one or
+more packed archives with the specified base-name to disk, or a packed
+archive to the standard output.
A packed archive is an efficient way to transfer a set of objects
between two repositories as well as an access efficient archival
@@ -47,9 +49,9 @@ transport by their peers.
OPTIONS
-------
base-name::
- Write into a pair of files (.pack and .idx), using
+ Write into pairs of files (.pack and .idx), using
<base-name> to determine the name of the created file.
- When this option is used, the two files are written in
+ When this option is used, the two files in a pair are written in
<base-name>-<SHA-1>.{pack,idx} files. <SHA-1> is a hash
based on the pack content and is written to the standard
output of the command.
@@ -94,7 +96,9 @@ base-name::
it too deep affects the performance on the unpacker
side, because delta data needs to be applied that many
times to get to the necessary object.
- The default value for --window is 10 and --depth is 50.
++
+The default value for --window is 10 and --depth is 50. The maximum
+depth is 4095.
--window-memory=<n>::
This option provides an additional limit on top of `--window`;
@@ -108,9 +112,13 @@ base-name::
is taken from the `pack.windowMemory` configuration variable.
--max-pack-size=<n>::
- Maximum size of each output pack file. The size can be suffixed with
+ In unusual scenarios, you may not be able to create files
+ larger than a certain size on your filesystem, and this option
+ can be used to tell the command to split the output packfile
+ into multiple independent packfiles, each not larger than the
+ given size. The size can be suffixed with
"k", "m", or "g". The minimum size allowed is limited to 1 MiB.
- If specified, multiple packfiles may be created, which also
+ This option
prevents the creation of a bitmap index.
The default is unlimited, unless the config variable
`pack.packSizeLimit` is set.
@@ -120,6 +128,13 @@ base-name::
has a .keep file to be ignored, even if it would have
otherwise been packed.
+--keep-pack=<pack-name>::
+ This flag causes an object already in the given pack to be
+ ignored, even if it would have otherwise been
+ packed. `<pack-name>` is the the pack file name without
+ leading directory (e.g. `pack-123.pack`). The option could be
+ specified multiple times to keep multiple packs.
+
--incremental::
This flag causes an object already in a pack to be ignored
even if it would have otherwise been packed.
@@ -181,6 +196,15 @@ base-name::
Add --no-reuse-object if you want to force a uniform compression
level on all data no matter the source.
+--sparse::
+ Use the "sparse" algorithm to determine which objects to include in
+ the pack, when combined with the "--revs" option. This algorithm
+ only walks trees that appear in paths that introduce new objects.
+ This can have significant performance benefits when computing
+ a pack to send a small change. However, it is possible that extra
+ objects are added to the pack-file if the included commits contain
+ certain types of direct renames.
+
--thin::
Create a "thin" pack by omitting the common objects between a
sender and a receiver in order to reduce network transfer. This
@@ -231,6 +255,146 @@ So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle.
With this option, parents that are hidden by grafts are packed
nevertheless.
+--filter=<filter-spec>::
+ Requires `--stdout`. Omits certain objects (usually blobs) from
+ the resulting packfile. See linkgit:git-rev-list[1] for valid
+ `<filter-spec>` forms.
+
+--no-filter::
+ Turns off any previous `--filter=` argument.
+
+--missing=<missing-action>::
+ A debug option to help with future "partial clone" development.
+ This option specifies how missing objects are handled.
++
+The form '--missing=error' requests that pack-objects stop with an error if
+a missing object is encountered. This is the default action.
++
+The form '--missing=allow-any' will allow object traversal to continue
+if a missing object is encountered. Missing objects will silently be
+omitted from the results.
++
+The form '--missing=allow-promisor' is like 'allow-any', but will only
+allow object traversal to continue for EXPECTED promisor missing objects.
+Unexpected missing object will raise an error.
+
+--exclude-promisor-objects::
+ Omit objects that are known to be in the promisor remote. (This
+ option has the purpose of operating only on locally created objects,
+ so that when we repack, we still maintain a distinction between
+ locally created objects [without .promisor] and objects from the
+ promisor remote [with .promisor].) This is used with partial clone.
+
+--keep-unreachable::
+ Objects unreachable from the refs in packs named with
+ --unpacked= option are added to the resulting pack, in
+ addition to the reachable objects that are not in packs marked
+ with *.keep files. This implies `--revs`.
+
+--pack-loose-unreachable::
+ Pack unreachable loose objects (and their loose counterparts
+ removed). This implies `--revs`.
+
+--unpack-unreachable::
+ Keep unreachable objects in loose form. This implies `--revs`.
+
+--delta-islands::
+ Restrict delta matches based on "islands". See DELTA ISLANDS
+ below.
+
+
+DELTA ISLANDS
+-------------
+
+When possible, `pack-objects` tries to reuse existing on-disk deltas to
+avoid having to search for new ones on the fly. This is an important
+optimization for serving fetches, because it means the server can avoid
+inflating most objects at all and just send the bytes directly from
+disk. This optimization can't work when an object is stored as a delta
+against a base which the receiver does not have (and which we are not
+already sending). In that case the server "breaks" the delta and has to
+find a new one, which has a high CPU cost. Therefore it's important for
+performance that the set of objects in on-disk delta relationships match
+what a client would fetch.
+
+In a normal repository, this tends to work automatically. The objects
+are mostly reachable from the branches and tags, and that's what clients
+fetch. Any deltas we find on the server are likely to be between objects
+the client has or will have.
+
+But in some repository setups, you may have several related but separate
+groups of ref tips, with clients tending to fetch those groups
+independently. For example, imagine that you are hosting several "forks"
+of a repository in a single shared object store, and letting clients
+view them as separate repositories through `GIT_NAMESPACE` or separate
+repos using the alternates mechanism. A naive repack may find that the
+optimal delta for an object is against a base that is only found in
+another fork. But when a client fetches, they will not have the base
+object, and we'll have to find a new delta on the fly.
+
+A similar situation may exist if you have many refs outside of
+`refs/heads/` and `refs/tags/` that point to related objects (e.g.,
+`refs/pull` or `refs/changes` used by some hosting providers). By
+default, clients fetch only heads and tags, and deltas against objects
+found only in those other groups cannot be sent as-is.
+
+Delta islands solve this problem by allowing you to group your refs into
+distinct "islands". Pack-objects computes which objects are reachable
+from which islands, and refuses to make a delta from an object `A`
+against a base which is not present in all of `A`'s islands. This
+results in slightly larger packs (because we miss some delta
+opportunities), but guarantees that a fetch of one island will not have
+to recompute deltas on the fly due to crossing island boundaries.
+
+When repacking with delta islands the delta window tends to get
+clogged with candidates that are forbidden by the config. Repacking
+with a big --window helps (and doesn't take as long as it otherwise
+might because we can reject some object pairs based on islands before
+doing any computation on the content).
+
+Islands are configured via the `pack.island` option, which can be
+specified multiple times. Each value is a left-anchored regular
+expressions matching refnames. For example:
+
+-------------------------------------------
+[pack]
+island = refs/heads/
+island = refs/tags/
+-------------------------------------------
+
+puts heads and tags into an island (whose name is the empty string; see
+below for more on naming). Any refs which do not match those regular
+expressions (e.g., `refs/pull/123`) is not in any island. Any object
+which is reachable only from `refs/pull/` (but not heads or tags) is
+therefore not a candidate to be used as a base for `refs/heads/`.
+
+Refs are grouped into islands based on their "names", and two regexes
+that produce the same name are considered to be in the same
+island. The names are computed from the regexes by concatenating any
+capture groups from the regex, with a '-' dash in between. (And if
+there are no capture groups, then the name is the empty string, as in
+the above example.) This allows you to create arbitrary numbers of
+islands. Only up to 14 such capture groups are supported though.
+
+For example, imagine you store the refs for each fork in
+`refs/virtual/ID`, where `ID` is a numeric identifier. You might then
+configure:
+
+-------------------------------------------
+[pack]
+island = refs/virtual/([0-9]+)/heads/
+island = refs/virtual/([0-9]+)/tags/
+island = refs/virtual/([0-9]+)/(pull)/
+-------------------------------------------
+
+That puts the heads and tags for each fork in their own island (named
+"1234" or similar), and the pull refs for each go into their own
+"1234-pull".
+
+Note that we pick a single island for each regex to go into, using "last
+one wins" ordering (which allows repo-specific config to take precedence
+over user-wide config, and so forth).
+
SEE ALSO
--------
linkgit:git-rev-list[1]
diff --git a/en/git-patch-id.txt b/en/git-patch-id.txt
index cf71fba1c0a9c18ea6428ab49820cb9e707608c6..442caff8a9c394168839e63f4612c9083386175a 100644
--- a/en/git-patch-id.txt
+++ b/en/git-patch-id.txt
@@ -56,9 +56,6 @@ OPTIONS
This is the default.
-<patch>::
- The diff to create the ID of.
-
GIT
---
Part of the linkgit:git[1] suite
diff --git a/en/git-prune.txt b/en/git-prune.txt
index 7a493c80f776092265abd4fb2575639e683bcf5c..03552dd86fc412b622aff2bcf8feda8e71711b3e 100644
--- a/en/git-prune.txt
+++ b/en/git-prune.txt
@@ -9,7 +9,7 @@ git-prune - Prune all unreachable objects from the object database
SYNOPSIS
--------
[verse]
-'git prune' [-n] [-v] [--expire <expire>] [--] [<head>...]
+'git prune' [-n] [-v] [--progress] [--expire <time>] [--] [<head>...]
DESCRIPTION
-----------
@@ -42,19 +42,22 @@ OPTIONS
--verbose::
Report all removed objects.
-\--::
- Do not interpret any more arguments as options.
+--progress::
+ Show progress.
--expire <time>::
Only expire loose objects older than <time>.
+\--::
+ Do not interpret any more arguments as options.
+
<head>...::
In addition to objects
reachable from any of our references, keep objects
reachable from listed <head>s.
-EXAMPLE
--------
+EXAMPLES
+--------
To prune objects not used by your repository or another that
borrows from your repository via its
@@ -64,7 +67,7 @@ borrows from your repository via its
$ git prune $(cd ../another && git rev-parse --all)
------------
-Notes
+NOTES
-----
In most cases, users will not need to call 'git prune' directly, but
diff --git a/en/git-pull.txt b/en/git-pull.txt
index 4470e4b5747f2474868fc0322823fff6aa25b841..118d9d86f79427373eb92753abf7e134ed925fe8 100644
--- a/en/git-pull.txt
+++ b/en/git-pull.txt
@@ -9,7 +9,7 @@ git-pull - Fetch from and integrate with another repository or a local branch
SYNOPSIS
--------
[verse]
-'git pull' [options] [<repository> [<refspec>...]]
+'git pull' [<options>] [<repository> [<refspec>...]]
DESCRIPTION
@@ -67,7 +67,7 @@ with uncommitted changes is discouraged: while possible, it leaves you
in a state that may be hard to back out of in the case of a conflict.
If any of the remote changes overlap with local uncommitted changes,
-the merge will be automatically cancelled and the work tree untouched.
+the merge will be automatically canceled and the work tree untouched.
It is generally best to get any local changes in working order before
pulling or stash them away with linkgit:git-stash[1].
@@ -86,12 +86,12 @@ OPTIONS
--[no-]recurse-submodules[=yes|on-demand|no]::
This option controls if new commits of all populated submodules should
- be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).
- That might be necessary to get the data needed for merging submodule
- commits, a feature Git learned in 1.7.3. Notice that the result of a
- merge will not be checked out in the submodule, "git submodule update"
- has to be called afterwards to bring the work tree up to date with the
- merge result.
+ be fetched and updated, too (see linkgit:git-config[1] and
+ linkgit:gitmodules[5]).
++
+If the checkout is done via rebase, local submodule commits are rebased as well.
++
+If the update is done via merge, the submodule conflicts are resolved and checked out.
Options related to merging
~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -101,13 +101,17 @@ Options related to merging
include::merge-options.txt[]
-r::
---rebase[=false|true|preserve|interactive]::
+--rebase[=false|true|merges|preserve|interactive]::
When true, rebase the current branch on top of the upstream
branch after fetching. If there is a remote-tracking branch
corresponding to the upstream branch and the upstream branch
was rebased since last fetched, the rebase uses that information
to avoid rebasing non-local changes.
+
+When set to `merges`, rebase using `git rebase --rebase-merges` so that
+the local merge commits are included in the rebase (see
+linkgit:git-rebase[1] for details).
++
When set to preserve, rebase with the `--preserve-merges` option passed
to `git rebase` so that locally created merge commits will not be flattened.
+
@@ -131,7 +135,7 @@ unless you have read linkgit:git-rebase[1] carefully.
--autostash::
--no-autostash::
Before starting rebase, stash local modifications away (see
- linkgit:git-stash[1]) if needed, and apply the stash when
+ linkgit:git-stash[1]) if needed, and apply the stash entry when
done. `--no-autostash` is useful to override the `rebase.autoStash`
configuration variable (see linkgit:git-config[1]).
+
@@ -159,15 +163,15 @@ present while on branch `<name>`, that value is used instead of
In order to determine what URL to use to fetch from, the value
of the configuration `remote.<origin>.url` is consulted
-and if there is not any such variable, the value on `URL: ` line
-in `$GIT_DIR/remotes/<origin>` file is used.
+and if there is not any such variable, the value on the `URL:` line
+in `$GIT_DIR/remotes/<origin>` is used.
In order to determine what remote branches to fetch (and
optionally store in the remote-tracking branches) when the command is
run without any refspec parameters on the command line, values
of the configuration variable `remote.<origin>.fetch` are
consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>`
-file is consulted and its `Pull: ` lines are used.
+is consulted and its `Pull:` lines are used.
In addition to the refspec formats described in the OPTIONS
section, you can have a globbing refspec that looks like this:
@@ -210,7 +214,8 @@ EXAMPLES
current branch:
+
------------------------------------------------
-$ git pull, git pull origin
+$ git pull
+$ git pull origin
------------------------------------------------
+
Normally the branch merged in is the HEAD of the remote repository,
diff --git a/en/git-push.txt b/en/git-push.txt
index 1624a35888c2e39f70b925a2f176d53dd02b809e..6a8a0d958bc63db19bfa4786e85e9e14061f1661 100644
--- a/en/git-push.txt
+++ b/en/git-push.txt
@@ -11,8 +11,8 @@ SYNOPSIS
[verse]
'git push' [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
- [-u | --set-upstream] [--push-option=<string>]
- [--[no-]signed|--sign=(true|false|if-asked)]
+ [-u | --set-upstream] [-o <string> | --push-option=<string>]
+ [--[no-]signed|--signed=(true|false|if-asked)]
[--force-with-lease[=<refname>[:<expect>]]]
[--no-verify] [<repository> [<refspec>...]]
@@ -73,23 +73,78 @@ be omitted--such a push will update a ref that `<src>` normally updates
without any `<refspec>` on the command line. Otherwise, missing
`:<dst>` means to update the same ref as the `<src>`.
+
+If <dst> doesn't start with `refs/` (e.g. `refs/heads/master`) we will
+try to infer where in `refs/*` on the destination <repository> it
+belongs based on the the type of <src> being pushed and whether <dst>
+is ambiguous.
++
+--
+* If <dst> unambiguously refers to a ref on the <repository> remote,
+ then push to that ref.
+
+* If <src> resolves to a ref starting with refs/heads/ or refs/tags/,
+ then prepend that to <dst>.
+
+* Other ambiguity resolutions might be added in the future, but for
+ now any other cases will error out with an error indicating what we
+ tried, and depending on the `advice.pushUnqualifiedRefname`
+ configuration (see linkgit:git-config[1]) suggest what refs/
+ namespace you may have wanted to push to.
+
+--
++
The object referenced by <src> is used to update the <dst> reference
-on the remote side. By default this is only allowed if <dst> is not
-a tag (annotated or lightweight), and then only if it can fast-forward
-<dst>. By having the optional leading `+`, you can tell Git to update
-the <dst> ref even if it is not allowed by default (e.g., it is not a
-fast-forward.) This does *not* attempt to merge <src> into <dst>. See
-EXAMPLES below for details.
+on the remote side. Whether this is allowed depends on where in
+`refs/*` the <dst> reference lives as described in detail below, in
+those sections "update" means any modifications except deletes, which
+as noted after the next few sections are treated differently.
+
-`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+The `refs/heads/*` namespace will only accept commit objects, and
+updates only if they can be fast-forwarded.
++
+The `refs/tags/*` namespace will accept any kind of object (as
+commits, trees and blobs can be tagged), and any updates to them will
+be rejected.
++
+It's possible to push any type of object to any namespace outside of
+`refs/{tags,heads}/*`. In the case of tags and commits, these will be
+treated as if they were the commits inside `refs/heads/*` for the
+purposes of whether the update is allowed.
++
+I.e. a fast-forward of commits and tags outside `refs/{tags,heads}/*`
+is allowed, even in cases where what's being fast-forwarded is not a
+commit, but a tag object which happens to point to a new commit which
+is a fast-forward of the commit the last tag (or commit) it's
+replacing. Replacing a tag with an entirely different tag is also
+allowed, if it points to the same commit, as well as pushing a peeled
+tag, i.e. pushing the commit that existing tag object points to, or a
+new tag object which an existing commit points to.
++
+Tree and blob objects outside of `refs/{tags,heads}/*` will be treated
+the same way as if they were inside `refs/tags/*`, any update of them
+will be rejected.
++
+All of the rules described above about what's not allowed as an update
+can be overridden by adding an the optional leading `+` to a refspec
+(or using `--force` command line option). The only exception to this
+is that no amount of forcing will make the `refs/heads/*` namespace
+accept a non-commit object. Hooks and configuration can also override
+or amend these rules, see e.g. `receive.denyNonFastForwards` in
+linkgit:git-config[1] and `pre-receive` and `update` in
+linkgit:githooks[5].
+
-Pushing an empty <src> allows you to delete the <dst> ref from
-the remote repository.
+Pushing an empty <src> allows you to delete the <dst> ref from the
+remote repository. Deletions are always accepted without a leading `+`
+in the refspec (or `--force`), except when forbidden by configuration
+or hooks. See `receive.denyDeletes` in linkgit:git-config[1] and
+`pre-receive` and `update` in linkgit:githooks[5].
+
The special refspec `:` (or `+:` to allow non-fast-forward updates)
directs Git to push "matching" branches: for every branch that exists on
the local side, the remote side is updated if a branch of the same name
already exists on the remote side.
++
+`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
--all::
Push all branches (i.e. refs under `refs/heads/`); cannot be
@@ -123,6 +178,7 @@ already exists on the remote side.
will be tab-separated and sent to stdout instead of stderr. The full
symbolic names of the refs will be given.
+-d::
--delete::
All listed refs are deleted from the remote repository. This is
the same as prefixing all refs with a colon.
@@ -141,7 +197,7 @@ already exists on the remote side.
information, see `push.followTags` in linkgit:git-config[1].
--[no-]signed::
---sign=(true|false|if-asked)::
+--signed=(true|false|if-asked)::
GPG-sign the push request to update refs on the receiving
side, to allow it to be checked by the hooks and/or be
logged. If `false` or `--no-signed`, no signing will be
@@ -156,11 +212,17 @@ already exists on the remote side.
Either all refs are updated, or on error, no refs are updated.
If the server does not support atomic pushes the push will fail.
--o::
---push-option::
+-o <option>::
+--push-option=<option>::
Transmit the given string to the server, which passes them to
the pre-receive as well as the post-receive hook. The given string
must not contain a NUL or LF character.
+ When multiple `--push-option=<option>` are given, they are
+ all sent to the other side in the order listed on the
+ command line.
+ When no `--push-option=<option>` is given from the command
+ line, the values of configuration variable `push.pushOption`
+ are used instead.
--receive-pack=<git-receive-pack>::
--exec=<git-receive-pack>::
@@ -217,6 +279,47 @@ with this feature.
+
"--no-force-with-lease" will cancel all the previous --force-with-lease on the
command line.
++
+A general note on safety: supplying this option without an expected
+value, i.e. as `--force-with-lease` or `--force-with-lease=<refname>`
+interacts very badly with anything that implicitly runs `git fetch` on
+the remote to be pushed to in the background, e.g. `git fetch origin`
+on your repository in a cronjob.
++
+The protection it offers over `--force` is ensuring that subsequent
+changes your work wasn't based on aren't clobbered, but this is
+trivially defeated if some background process is updating refs in the
+background. We don't have anything except the remote tracking info to
+go by as a heuristic for refs you're expected to have seen & are
+willing to clobber.
++
+If your editor or some other system is running `git fetch` in the
+background for you a way to mitigate this is to simply set up another
+remote:
++
+ git remote add origin-push $(git config remote.origin.url)
+ git fetch origin-push
++
+Now when the background process runs `git fetch origin` the references
+on `origin-push` won't be updated, and thus commands like:
++
+ git push --force-with-lease origin-push
++
+Will fail unless you manually run `git fetch origin-push`. This method
+is of course entirely defeated by something that runs `git fetch
+--all`, in that case you'd need to either disable it or do something
+more tedious like:
++
+ git fetch # update 'master' from remote
+ git tag base master # mark our base point
+ git rebase -i master # rewrite some commits
+ git push --force-with-lease=master:base master:master
++
+I.e. create a `base` tag for versions of the upstream code that you've
+seen and are willing to overwrite, then rewrite history, and finally
+force push changes to `master` if the remote version is still at
+`base`, regardless of what your local `remotes/origin/master` has been
+updated to in the background.
-f::
--force::
@@ -253,7 +356,7 @@ origin +master` to force a push to the `master` branch). See the
These options are passed to linkgit:git-send-pack[1]. A thin transfer
significantly reduces the amount of sent data when the sender and
receiver share many of the same objects in common. The default is
- \--thin.
+ `--thin`.
-q::
--quiet::
@@ -376,7 +479,7 @@ reason::
refs, no explanation is needed. For a failed ref, the reason for
failure is described.
-Note about fast-forwards
+NOTE ABOUT FAST-FORWARDS
------------------------
When an update changes a branch (or more in general, a ref) that used to
@@ -463,7 +566,7 @@ overwrite it. In other words, "git push --force" is a method reserved for
a case where you do mean to lose history.
-Examples
+EXAMPLES
--------
`git push`::
@@ -508,6 +611,9 @@ the ones in the examples below) can be configured as the default for
`refs/remotes/satellite/master`) in the `mothership` repository;
do the same for `dev` and `satellite/dev`.
+
+See the section describing `<refspec>...` above for a discussion of
+the matching semantics.
++
This is to emulate `git fetch` run on the `mothership` using `git
push` that is run in the opposite direction in order to integrate
the work done on `satellite`, and is often necessary when you can
diff --git a/en/git-quiltimport.txt b/en/git-quiltimport.txt
index 8cf952b4de669ea3e7275c5d10087005548574eb..70562dc4c0235d53501bab56ff98af6169b8f968 100644
--- a/en/git-quiltimport.txt
+++ b/en/git-quiltimport.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git quiltimport' [--dry-run | -n] [--author <author>] [--patches <dir>]
- [--series <file>]
+ [--series <file>] [--keep-non-patch]
DESCRIPTION
@@ -56,6 +56,9 @@ The default for the series file is <patches>/series
or the value of the `$QUILT_SERIES` environment
variable.
+--keep-non-patch::
+ Pass `-b` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/en/git-read-tree.txt b/en/git-read-tree.txt
index fa1d557e5b98eb6dc40e3baa65964138b4cc0621..5c70bc2878fc2f68698b931c6bf951d0097ef813 100644
--- a/en/git-read-tree.txt
+++ b/en/git-read-tree.txt
@@ -81,12 +81,11 @@ OPTIONS
* when both sides add a path identically. The resolution
is to add that path.
---prefix=<prefix>/::
+--prefix=<prefix>::
Keep the current index contents, and read the contents
of the named tree-ish under the directory at `<prefix>`.
The command will refuse to overwrite entries that already
- existed in the original index file. Note that the `<prefix>/`
- value must end with a slash.
+ existed in the original index file.
--exclude-per-directory=<gitignore>::
When running the command with `-u` and `-m` options, the
@@ -115,6 +114,12 @@ OPTIONS
directories the index file and index output file are
located in.
+--[no-]recurse-submodules::
+ Using --recurse-submodules will update the content of all initialized
+ submodules according to the commit recorded in the superproject by
+ calling read-tree recursively, also setting the submodules HEAD to be
+ detached at that commit.
+
--no-sparse-checkout::
Disable sparse checkout support even if `core.sparseCheckout`
is true.
@@ -127,11 +132,11 @@ OPTIONS
The id of the tree object(s) to be read/merged.
-Merging
+MERGING
-------
If `-m` is specified, 'git read-tree' can perform 3 kinds of
merge, a single tree merge if only 1 tree is given, a
-fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
+fast-forward merge with 2 trees, or a 3-way merge if 3 or more trees are
provided.
@@ -173,6 +178,7 @@ Here are the "carry forward" rules, where "I" denotes the index,
"clean" means that index and work tree coincide, and "exists"/"nothing"
refer to the presence of a path in the specified commit:
+....
I H M Result
-------------------------------------------------------
0 nothing nothing nothing (does not happen)
@@ -211,6 +217,7 @@ refer to the presence of a path in the specified commit:
19 no no yes exists exists keep index
20 yes yes no exists exists use M
21 no yes no exists exists fail
+....
In all "keep index" cases, the index entry stays as in the
original index file. If the entry is not up to date,
@@ -375,7 +382,7 @@ middle of doing, and when your working tree is ready (i.e. you
have finished your work-in-progress), attempt the merge again.
-Sparse checkout
+SPARSE CHECKOUT
---------------
"Sparse checkout" allows populating the working directory sparsely.
diff --git a/en/git-rebase.txt b/en/git-rebase.txt
index 67d48e68831561303c4f39f46bf105371ed0d916..daa16403ece9f0f050da5a24086e89b181d9c0fa 100644
--- a/en/git-rebase.txt
+++ b/en/git-rebase.txt
@@ -8,11 +8,11 @@ git-rebase - Reapply commits on top of another base tip
SYNOPSIS
--------
[verse]
-'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
+'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
[<upstream> [<branch>]]
-'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
+'git rebase' [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
--root [<branch>]
-'git rebase' --continue | --skip | --abort | --quit | --edit-todo
+'git rebase' --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch
DESCRIPTION
-----------
@@ -203,24 +203,7 @@ Alternatively, you can undo the 'git rebase' with
CONFIGURATION
-------------
-rebase.stat::
- Whether to show a diffstat of what changed upstream since the last
- rebase. False by default.
-
-rebase.autoSquash::
- If set to true enable `--autosquash` option by default.
-
-rebase.autoStash::
- If set to true enable `--autostash` option by default.
-
-rebase.missingCommitsCheck::
- If set to "warn", print warnings about removed commits in
- interactive mode. If set to "error", print the warnings and
- stop the rebase. If set to "ignore", no checking is
- done. "ignore" by default.
-
-rebase.instructionFormat::
- Custom commit list format to use during an `--interactive` rebase.
+include::config/rebase.txt[]
OPTIONS
-------
@@ -260,6 +243,15 @@ leave out at most one of A and B, in which case it defaults to HEAD.
--keep-empty::
Keep the commits that do not change anything from its
parents in the result.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--allow-empty-message::
+ By default, rebasing commits with an empty message will fail.
+ This option overrides that behavior, allowing commits with empty
+ messages to be rebased.
++
+See also INCOMPATIBLE OPTIONS below.
--skip::
Restart the rebasing process by skipping the current patch.
@@ -267,6 +259,11 @@ leave out at most one of A and B, in which case it defaults to HEAD.
--edit-todo::
Edit the todo list during an interactive rebase.
+--show-current-patch::
+ Show the current patch in an interactive rebase or when rebase
+ is stopped because of conflicts. This is the equivalent of
+ `git show REBASE_HEAD`.
+
-m::
--merge::
Use merging strategies to rebase. When the recursive (default) merge
@@ -278,6 +275,8 @@ branch on top of the <upstream> branch. Because of this, when a merge
conflict happens, the side reported as 'ours' is the so-far rebased
series, starting with <upstream>, and 'theirs' is the working branch. In
other words, the sides are swapped.
++
+See also INCOMPATIBLE OPTIONS below.
-s <strategy>::
--strategy=<strategy>::
@@ -287,8 +286,10 @@ other words, the sides are swapped.
+
Because 'git rebase' replays each commit from the working branch
on top of the <upstream> branch using the given strategy, using
-the 'ours' strategy simply discards all patches from the <branch>,
+the 'ours' strategy simply empties all patches from the <branch>,
which makes little sense.
++
+See also INCOMPATIBLE OPTIONS below.
-X <strategy-option>::
--strategy-option=<strategy-option>::
@@ -296,6 +297,8 @@ which makes little sense.
This implies `--merge` and, if no strategy has been
specified, `-s recursive`. Note the reversal of 'ours' and
'theirs' as noted above for the `-m` option.
++
+See also INCOMPATIBLE OPTIONS below.
-S[<keyid>]::
--gpg-sign[=<keyid>]::
@@ -331,17 +334,21 @@ which makes little sense.
and after each change. When fewer lines of surrounding
context exist they all must match. By default no context is
ever ignored.
++
+See also INCOMPATIBLE OPTIONS below.
--f::
+--no-ff::
--force-rebase::
- Force a rebase even if the current branch is up-to-date and
- the command without `--force` would return without doing anything.
+-f::
+ Individually replay all rebased commits instead of fast-forwarding
+ over the unchanged ones. This ensures that the entire history of
+ the rebased branch is composed of new commits.
+
-You may find this (or --no-ff with an interactive rebase) helpful after
-reverting a topic branch merge, as this option recreates the topic branch with
-fresh commits so it can be remerged successfully without needing to "revert
-the reversion" (see the
-link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details).
+You may find this helpful after reverting a topic branch merge, as this option
+recreates the topic branch with fresh commits so it can be remerged
+successfully without needing to "revert the reversion" (see the
+link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for
+details).
--fork-point::
--no-fork-point::
@@ -362,13 +369,22 @@ default is `--no-fork-point`, otherwise the default is `--fork-point`.
--whitespace=<option>::
These flag are passed to the 'git apply' program
(see linkgit:git-apply[1]) that applies the patch.
- Incompatible with the --interactive option.
++
+See also INCOMPATIBLE OPTIONS below.
--committer-date-is-author-date::
--ignore-date::
These flags are passed to 'git am' to easily change the dates
of the rebased commits (see linkgit:git-am[1]).
- Incompatible with the --interactive option.
++
+See also INCOMPATIBLE OPTIONS below.
+
+--signoff::
+ Add a Signed-off-by: trailer to all the rebased commits. Note
+ that if `--interactive` is given then only commits marked to be
+ picked, edited or reworded will have the trailer added.
++
+See also INCOMPATIBLE OPTIONS below.
-i::
--interactive::
@@ -379,6 +395,35 @@ default is `--no-fork-point`, otherwise the default is `--fork-point`.
The commit list format can be changed by setting the configuration option
rebase.instructionFormat. A customized instruction format will automatically
have the long commit hash prepended to the format.
++
+See also INCOMPATIBLE OPTIONS below.
+
+-r::
+--rebase-merges[=(rebase-cousins|no-rebase-cousins)]::
+ By default, a rebase will simply drop merge commits from the todo
+ list, and put the rebased commits into a single, linear branch.
+ With `--rebase-merges`, the rebase will instead try to preserve
+ the branching structure within the commits that are to be rebased,
+ by recreating the merge commits. Any resolved merge conflicts or
+ manual amendments in these merge commits will have to be
+ resolved/re-applied manually.
++
+By default, or when `no-rebase-cousins` was specified, commits which do not
+have `<upstream>` as direct ancestor will keep their original branch point,
+i.e. commits that would be excluded by gitlink:git-log[1]'s
+`--ancestry-path` option will keep their original ancestry by default. If
+the `rebase-cousins` mode is turned on, such commits are instead rebased
+onto `<upstream>` (or `<onto>`, if specified).
++
+The `--rebase-merges` mode is similar in spirit to `--preserve-merges`, but
+in contrast to that option works well in interactive rebases: commits can be
+reordered, inserted and dropped at will.
++
+It is currently only possible to recreate the merge commits using the
+`recursive` merge strategy; Different merge strategies can be used only via
+explicit `exec git merge -s <strategy> [...]` commands.
++
+See also REBASING MERGES and INCOMPATIBLE OPTIONS below.
-p::
--preserve-merges::
@@ -389,12 +434,15 @@ have the long commit hash prepended to the format.
This uses the `--interactive` machinery internally, but combining it
with the `--interactive` option explicitly is generally not a good
idea unless you know what you are doing (see BUGS below).
++
+See also INCOMPATIBLE OPTIONS below.
-x <cmd>::
--exec <cmd>::
Append "exec <cmd>" after each line creating a commit in the
final history. <cmd> will be interpreted as one or more shell
- commands.
+ commands. Any command that fails will interrupt the rebase,
+ with exit code 1.
+
You may execute several commands by either using one instance of `--exec`
with several commands:
@@ -411,6 +459,8 @@ squash/fixup series.
+
This uses the `--interactive` machinery internally, but it can be run
without an explicit `--interactive`.
++
+See also INCOMPATIBLE OPTIONS below.
--root::
Rebase all commits reachable from <branch>, instead of
@@ -421,43 +471,102 @@ without an explicit `--interactive`.
When used together with both --onto and --preserve-merges,
'all' root commits will be rewritten to have <newbase> as parent
instead.
++
+See also INCOMPATIBLE OPTIONS below.
--autosquash::
--no-autosquash::
When the commit log message begins with "squash! ..." (or
- "fixup! ..."), and there is a commit whose title begins with
- the same ..., automatically modify the todo list of rebase -i
- so that the commit marked for squashing comes right after the
- commit to be modified, and change the action of the moved
- commit from `pick` to `squash` (or `fixup`). Ignores subsequent
- "fixup! " or "squash! " after the first, in case you referred to an
- earlier fixup/squash with `git commit --fixup/--squash`.
-+
-This option is only valid when the `--interactive` option is used.
+ "fixup! ..."), and there is already a commit in the todo list that
+ matches the same `...`, automatically modify the todo list of rebase
+ -i so that the commit marked for squashing comes right after the
+ commit to be modified, and change the action of the moved commit
+ from `pick` to `squash` (or `fixup`). A commit matches the `...` if
+ the commit subject matches, or if the `...` refers to the commit's
+ hash. As a fall-back, partial matches of the commit subject work,
+ too. The recommended way to create fixup/squash commits is by using
+ the `--fixup`/`--squash` options of linkgit:git-commit[1].
+
If the `--autosquash` option is enabled by default using the
configuration variable `rebase.autoSquash`, this option can be
used to override and disable this setting.
++
+See also INCOMPATIBLE OPTIONS below.
--autostash::
--no-autostash::
- Automatically create a temporary stash before the operation
+ Automatically create a temporary stash entry before the operation
begins, and apply it after the operation ends. This means
that you can run rebase on a dirty worktree. However, use
with care: the final stash application after a successful
rebase might result in non-trivial conflicts.
---no-ff::
- With --interactive, cherry-pick all rebased commits instead of
- fast-forwarding over the unchanged ones. This ensures that the
- entire history of the rebased branch is composed of new commits.
-+
-Without --interactive, this is a synonym for --force-rebase.
-+
-You may find this helpful after reverting a topic branch merge, as this option
-recreates the topic branch with fresh commits so it can be remerged
-successfully without needing to "revert the reversion" (see the
-link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details).
+--reschedule-failed-exec::
+--no-reschedule-failed-exec::
+ Automatically reschedule `exec` commands that failed. This only makes
+ sense in interactive mode (or when an `--exec` option was provided).
+
+INCOMPATIBLE OPTIONS
+--------------------
+
+The following options:
+
+ * --committer-date-is-author-date
+ * --ignore-date
+ * --whitespace
+ * --ignore-whitespace
+ * -C
+
+are incompatible with the following options:
+
+ * --merge
+ * --strategy
+ * --strategy-option
+ * --allow-empty-message
+ * --[no-]autosquash
+ * --rebase-merges
+ * --preserve-merges
+ * --interactive
+ * --exec
+ * --keep-empty
+ * --autosquash
+ * --edit-todo
+ * --root when used in combination with --onto
+
+In addition, the following pairs of options are incompatible:
+
+ * --preserve-merges and --interactive
+ * --preserve-merges and --signoff
+ * --preserve-merges and --rebase-merges
+ * --rebase-merges and --strategy
+ * --rebase-merges and --strategy-option
+
+BEHAVIORAL DIFFERENCES
+-----------------------
+
+There are some subtle differences how the backends behave.
+
+Empty commits
+~~~~~~~~~~~~~
+
+The am backend drops any "empty" commits, regardless of whether the
+commit started empty (had no changes relative to its parent to
+start with) or ended empty (all changes were already applied
+upstream in other commits).
+
+The merge backend does the same.
+
+The interactive backend drops commits by default that
+started empty and halts if it hits a commit that ended up empty.
+The `--keep-empty` option exists for the interactive backend to allow
+it to keep commits that started empty.
+
+Directory rename detection
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Directory rename heuristics are enabled in the merge and interactive
+backends. Due to the lack of accurate tree information, directory
+rename detection is disabled in the am backend.
include::merge-strategies.txt[]
@@ -532,6 +641,9 @@ By replacing the command "pick" with the command "edit", you can tell
the files and/or the commit message, amend the commit, and continue
rebasing.
+To interrupt the rebase (just like an "edit" command would do, but without
+cherry-picking any commit first), use the "break" command.
+
If you just want to edit the commit message for a commit, replace the
command "pick" with the command "reword".
@@ -670,7 +782,7 @@ on this 'subsystem'. You might end up with a history like the
following:
------------
- o---o---o---o---o---o---o---o---o master
+ o---o---o---o---o---o---o---o master
\
o---o---o---o---o subsystem
\
@@ -775,12 +887,147 @@ The ripple effect of a "hard case" recovery is especially bad:
'everyone' downstream from 'topic' will now have to perform a "hard
case" recovery too!
+REBASING MERGES
+---------------
+
+The interactive rebase command was originally designed to handle
+individual patch series. As such, it makes sense to exclude merge
+commits from the todo list, as the developer may have merged the
+then-current `master` while working on the branch, only to rebase
+all the commits onto `master` eventually (skipping the merge
+commits).
+
+However, there are legitimate reasons why a developer may want to
+recreate merge commits: to keep the branch structure (or "commit
+topology") when working on multiple, inter-related branches.
+
+In the following example, the developer works on a topic branch that
+refactors the way buttons are defined, and on another topic branch
+that uses that refactoring to implement a "Report a bug" button. The
+output of `git log --graph --format=%s -5` may look like this:
+
+------------
+* Merge branch 'report-a-bug'
+|\
+| * Add the feedback button
+* | Merge branch 'refactor-button'
+|\ \
+| |/
+| * Use the Button class for all buttons
+| * Extract a generic Button class from the DownloadButton one
+------------
+
+The developer might want to rebase those commits to a newer `master`
+while keeping the branch topology, for example when the first topic
+branch is expected to be integrated into `master` much earlier than the
+second one, say, to resolve merge conflicts with changes to the
+DownloadButton class that made it into `master`.
+
+This rebase can be performed using the `--rebase-merges` option.
+It will generate a todo list looking like this:
+
+------------
+label onto
+
+# Branch: refactor-button
+reset onto
+pick 123456 Extract a generic Button class from the DownloadButton one
+pick 654321 Use the Button class for all buttons
+label refactor-button
+
+# Branch: report-a-bug
+reset refactor-button # Use the Button class for all buttons
+pick abcdef Add the feedback button
+label report-a-bug
+
+reset onto
+merge -C a1b2c3 refactor-button # Merge 'refactor-button'
+merge -C 6f5e4d report-a-bug # Merge 'report-a-bug'
+------------
+
+In contrast to a regular interactive rebase, there are `label`, `reset`
+and `merge` commands in addition to `pick` ones.
+
+The `label` command associates a label with the current HEAD when that
+command is executed. These labels are created as worktree-local refs
+(`refs/rewritten/<label>`) that will be deleted when the rebase
+finishes. That way, rebase operations in multiple worktrees linked to
+the same repository do not interfere with one another. If the `label`
+command fails, it is rescheduled immediately, with a helpful message how
+to proceed.
+
+The `reset` command resets the HEAD, index and worktree to the specified
+revision. It is similar to an `exec git reset --hard <label>`, but
+refuses to overwrite untracked files. If the `reset` command fails, it is
+rescheduled immediately, with a helpful message how to edit the todo list
+(this typically happens when a `reset` command was inserted into the todo
+list manually and contains a typo).
+
+The `merge` command will merge the specified revision(s) into whatever
+is HEAD at that time. With `-C <original-commit>`, the commit message of
+the specified merge commit will be used. When the `-C` is changed to
+a lower-case `-c`, the message will be opened in an editor after a
+successful merge so that the user can edit the message.
+
+If a `merge` command fails for any reason other than merge conflicts (i.e.
+when the merge operation did not even start), it is rescheduled immediately.
+
+At this time, the `merge` command will *always* use the `recursive`
+merge strategy for regular merges, and `octopus` for octopus merges,
+with no way to choose a different one. To work around
+this, an `exec` command can be used to call `git merge` explicitly,
+using the fact that the labels are worktree-local refs (the ref
+`refs/rewritten/onto` would correspond to the label `onto`, for example).
+
+Note: the first command (`label onto`) labels the revision onto which
+the commits are rebased; The name `onto` is just a convention, as a nod
+to the `--onto` option.
+
+It is also possible to introduce completely new merge commits from scratch
+by adding a command of the form `merge <merge-head>`. This form will
+generate a tentative commit message and always open an editor to let the
+user edit it. This can be useful e.g. when a topic branch turns out to
+address more than a single concern and wants to be split into two or
+even more topic branches. Consider this todo list:
+
+------------
+pick 192837 Switch from GNU Makefiles to CMake
+pick 5a6c7e Document the switch to CMake
+pick 918273 Fix detection of OpenSSL in CMake
+pick afbecd http: add support for TLS v1.3
+pick fdbaec Fix detection of cURL in CMake on Windows
+------------
+
+The one commit in this list that is not related to CMake may very well
+have been motivated by working on fixing all those bugs introduced by
+switching to CMake, but it addresses a different concern. To split this
+branch into two topic branches, the todo list could be edited like this:
+
+------------
+label onto
+
+pick afbecd http: add support for TLS v1.3
+label tlsv1.3
+
+reset onto
+pick 192837 Switch from GNU Makefiles to CMake
+pick 918273 Fix detection of OpenSSL in CMake
+pick fdbaec Fix detection of cURL in CMake on Windows
+pick 5a6c7e Document the switch to CMake
+label cmake
+
+reset onto
+merge tlsv1.3
+merge cmake
+------------
+
BUGS
----
The todo list presented by `--preserve-merges --interactive` does not
represent the topology of the revision graph. Editing commits and
rewording their commit messages should work fine, but attempts to
-reorder commits tend to produce counterintuitive results.
+reorder commits tend to produce counterintuitive results. Use
+`--rebase-merges` in such scenarios instead.
For example, an attempt to rearrange
------------
diff --git a/en/git-receive-pack.txt b/en/git-receive-pack.txt
index 0ccd5fbc781deb3adcca4d28ec8a4ed0d9db9977..dedf97efbb2282a15abfee41926afd893e59955c 100644
--- a/en/git-receive-pack.txt
+++ b/en/git-receive-pack.txt
@@ -41,7 +41,7 @@ OPTIONS
<directory>::
The repository to sync into.
-pre-receive Hook
+PRE-RECEIVE HOOK
----------------
Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists
and is executable, it will be invoked once with no parameters. The
@@ -114,7 +114,9 @@ will be performed, and the update, post-receive and post-update
hooks will not be invoked either. This can be useful to quickly
bail out if the update is not to be supported.
-update Hook
+See the notes on the quarantine environment below.
+
+UPDATE HOOK
-----------
Before each ref is updated, if $GIT_DIR/hooks/update file exists
and is executable, it is invoked once per ref, with three parameters:
@@ -136,7 +138,7 @@ ensure the ref will actually be updated, it is only a prerequisite.
As such it is not a good idea to send notices (e.g. email) from
this hook. Consider using the post-receive hook instead.
-post-receive Hook
+POST-RECEIVE HOOK
-----------------
After all refs were updated (or attempted to be updated), if any
ref update was successful, and if $GIT_DIR/hooks/post-receive
@@ -196,7 +198,7 @@ after it was updated by 'git-receive-pack', but before the hook was able
to evaluate it. It is recommended that hooks rely on sha1-new
rather than the current value of refname.
-post-update Hook
+POST-UPDATE HOOK
----------------
After all other processing, if at least one ref was updated, and
if $GIT_DIR/hooks/post-update file exists and is executable, then
@@ -214,6 +216,33 @@ if the repository is packed and is served via a dumb transport.
exec git update-server-info
+QUARANTINE ENVIRONMENT
+----------------------
+
+When `receive-pack` takes in objects, they are placed into a temporary
+"quarantine" directory within the `$GIT_DIR/objects` directory and
+migrated into the main object store only after the `pre-receive` hook
+has completed. If the push fails before then, the temporary directory is
+removed entirely.
+
+This has a few user-visible effects and caveats:
+
+ 1. Pushes which fail due to problems with the incoming pack, missing
+ objects, or due to the `pre-receive` hook will not leave any
+ on-disk data. This is usually helpful to prevent repeated failed
+ pushes from filling up your disk, but can make debugging more
+ challenging.
+
+ 2. Any objects created by the `pre-receive` hook will be created in
+ the quarantine directory (and migrated only if it succeeds).
+
+ 3. The `pre-receive` hook MUST NOT update any refs to point to
+ quarantined objects. Other programs accessing the repository will
+ not be able to see the objects (and if the pre-receive hook fails,
+ those refs would become corrupted). For safety, any ref updates
+ from within `pre-receive` are automatically rejected.
+
+
SEE ALSO
--------
linkgit:git-send-pack[1], linkgit:gitnamespaces[7]
diff --git a/en/git-reflog.txt b/en/git-reflog.txt
index 44c736f1a8e581bc072d5de3b719284f7376ec3b..ff487ff77d397207431c8e3d9e56f3c5da5a2791 100644
--- a/en/git-reflog.txt
+++ b/en/git-reflog.txt
@@ -20,9 +20,9 @@ depending on the subcommand:
'git reflog' ['show'] [log-options] [<ref>]
'git reflog expire' [--expire=<time>] [--expire-unreachable=<time>]
[--rewrite] [--updateref] [--stale-fix]
- [--dry-run] [--verbose] [--all | <refs>...]
+ [--dry-run | -n] [--verbose] [--all [--single-worktree] | <refs>...]
'git reflog delete' [--rewrite] [--updateref]
- [--dry-run] [--verbose] ref@\{specifier\}...
+ [--dry-run | -n] [--verbose] ref@\{specifier\}...
'git reflog exists' <ref>
Reference logs, or "reflogs", record when the tips of branches and
@@ -72,6 +72,11 @@ Options for `expire`
--all::
Process the reflogs of all references.
+--single-worktree::
+ By default when `--all` is specified, reflogs from all working
+ trees are processed. This option limits the processing to reflogs
+ from the current working tree only.
+
--expire=<time>::
Prune entries older than the specified time. If this option is
not specified, the expiration time is taken from the
diff --git a/en/git-remote-ext.txt b/en/git-remote-ext.txt
index b25d0b5996b560837648c13c742bfc5ad09f0310..3fc5d94336f7c706bab12513e14744947a0bcae2 100644
--- a/en/git-remote-ext.txt
+++ b/en/git-remote-ext.txt
@@ -55,14 +55,14 @@ some tunnel.
the vhost field in the git:// service request (to rest of the argument).
Default is not to send vhost in such request (if sent).
-ENVIRONMENT VARIABLES:
-----------------------
+ENVIRONMENT VARIABLES
+---------------------
GIT_TRANSLOOP_DEBUG::
If set, prints debugging information about various reads/writes.
-ENVIRONMENT VARIABLES PASSED TO COMMAND:
-----------------------------------------
+ENVIRONMENT VARIABLES PASSED TO COMMAND
+---------------------------------------
GIT_EXT_SERVICE::
Set to long name (git-upload-pack, etc...) of service helper needs
@@ -73,8 +73,8 @@ GIT_EXT_SERVICE_NOPREFIX::
to invoke.
-EXAMPLES:
----------
+EXAMPLES
+--------
This remote helper is transparently used by Git when
you use commands such as "git fetch <URL>", "git clone <URL>",
, "git push <URL>" or "git remote add <nick> <URL>", where <URL>
diff --git a/en/git-remote.txt b/en/git-remote.txt
index 577b969c1bda2bfd95fd28e3ffc4bbbc96c5d16c..0cad37fb81d99c3928f1a763a79350836b8e70e6 100644
--- a/en/git-remote.txt
+++ b/en/git-remote.txt
@@ -172,24 +172,28 @@ With `-n` option, the remote heads are not queried first with
'prune'::
-Deletes all stale remote-tracking branches under <name>.
-These stale branches have already been removed from the remote repository
-referenced by <name>, but are still locally available in
-"remotes/<name>".
+Deletes stale references associated with <name>. By default, stale
+remote-tracking branches under <name> are deleted, but depending on
+global configuration and the configuration of the remote we might even
+prune local tags that haven't been pushed there. Equivalent to `git
+fetch --prune <name>`, except that no new references will be fetched.
++
+See the PRUNING section of linkgit:git-fetch[1] for what it'll prune
+depending on various configuration.
+
With `--dry-run` option, report what branches will be pruned, but do not
actually prune them.
'update'::
-Fetch updates for a named set of remotes in the repository as defined by
-remotes.<group>. If a named group is not specified on the command line,
+Fetch updates for remotes or remote groups in the repository as defined by
+remotes.<group>. If neither group nor remote is specified on the command line,
the configuration parameter remotes.default will be used; if
remotes.default is not defined, all remotes which do not have the
configuration parameter remote.<name>.skipDefaultUpdate set to true will
be updated. (See linkgit:git-config[1]).
+
-With `--prune` option, prune all the remotes that are updated.
+With `--prune` option, run pruning against all the remotes that are updated.
DISCUSSION
@@ -199,7 +203,7 @@ The remote configuration is achieved using the `remote.origin.url` and
`remote.origin.fetch` configuration variables. (See
linkgit:git-config[1]).
-Examples
+EXAMPLES
--------
* Add a new remote, fetch, and check out a branch from it
diff --git a/en/git-repack.txt b/en/git-repack.txt
index 26afe6ed549002f83296e76d8be6502332bc7edf..aa0cc8bd445c99703d6ee17346d656104194dda8 100644
--- a/en/git-repack.txt
+++ b/en/git-repack.txt
@@ -9,7 +9,7 @@ git-repack - Pack unpacked objects in a repository
SYNOPSIS
--------
[verse]
-'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [--window=<n>] [--depth=<n>]
+'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>]
DESCRIPTION
-----------
@@ -40,6 +40,11 @@ OPTIONS
Note that users fetching over dumb protocols will have to fetch the
whole new pack in order to get any contained object, no matter how many
other objects in that pack they already have locally.
++
+Promisor packfiles are repacked separately: if there are packfiles that
+have an associated ".promisor" file, these packfiles will be repacked
+into another separate pack, and an empty ".promisor" file corresponding
+to the new separate pack will be written.
-A::
Same as `-a`, unless `-d` is used. Then any unreachable
@@ -90,7 +95,12 @@ other objects in that pack they already have locally.
space. `--depth` limits the maximum delta depth; making it too deep
affects the performance on the unpacker side, because delta data needs
to be applied that many times to get to the necessary object.
- The default value for --window is 10 and --depth is 50.
++
+The default value for --window is 10 and --depth is 50. The maximum
+depth is 4095.
+
+--threads=<n>::
+ This option is passed through to `git pack-objects`.
--window-memory=<n>::
This option provides an additional limit on top of `--window`;
@@ -130,6 +140,13 @@ other objects in that pack they already have locally.
with `-b` or `repack.writeBitmaps`, as it ensures that the
bitmapped packfile has the necessary objects.
+--keep-pack=<pack-name>::
+ Exclude the given pack from repacking. This is the equivalent
+ of having `.keep` file on the pack. `<pack-name>` is the the
+ pack file name without leading directory (e.g. `pack-123.pack`).
+ The option could be specified multiple times to keep multiple
+ packs.
+
--unpack-unreachable=<when>::
When loosening unreachable objects, do not bother loosening any
objects older than `<when>`. This can be used to optimize out
@@ -143,6 +160,11 @@ other objects in that pack they already have locally.
being removed. In addition, any unreachable loose objects will
be packed (and their loose counterparts removed).
+-i::
+--delta-islands::
+ Pass the `--delta-islands` option to `git-pack-objects`, see
+ linkgit:git-pack-objects[1].
+
Configuration
-------------
diff --git a/en/git-replace.txt b/en/git-replace.txt
index e5c57ae6ef4afd71944e23f895e9a0f354eaf6b1..246dc9943c223d34c72d7b90f40ee8f523b7d77e 100644
--- a/en/git-replace.txt
+++ b/en/git-replace.txt
@@ -11,6 +11,7 @@ SYNOPSIS
'git replace' [-f] <object> <replacement>
'git replace' [-f] --edit <object>
'git replace' [-f] --graft <commit> [<parent>...]
+'git replace' [-f] --convert-graft-file
'git replace' -d <object>...
'git replace' [--format=<format>] [-l [<pattern>]]
@@ -87,9 +88,13 @@ OPTIONS
content as <commit> except that its parents will be
[<parent>...] instead of <commit>'s parents. A replacement ref
is then created to replace <commit> with the newly created
- commit. See contrib/convert-grafts-to-replace-refs.sh for an
- example script based on this option that can convert grafts to
- replace refs.
+ commit. Use `--convert-graft-file` to convert a
+ `$GIT_DIR/info/grafts` file and use replace refs instead.
+
+--convert-graft-file::
+ Creates graft commits for all entries in `$GIT_DIR/info/grafts`
+ and deletes that file upon success. The purpose is to help users
+ with transitioning off of the now-deprecated graft file.
-l <pattern>::
--list <pattern>::
diff --git a/en/git-request-pull.txt b/en/git-request-pull.txt
index c32cb0bea1d6c057dabdd3065417744f5209ba46..4d4392d0f841b7e447b536ef1281fcbe2e49786d 100644
--- a/en/git-request-pull.txt
+++ b/en/git-request-pull.txt
@@ -46,8 +46,8 @@ ref that is different from the ref you have locally, you can use the
its remote name.
-EXAMPLE
--------
+EXAMPLES
+--------
Imagine that you built your work on your `master` branch on top of
the `v1.0` release, and want it to be integrated to the project.
diff --git a/en/git-rerere.txt b/en/git-rerere.txt
index 9ee083c415a27dc499b75031d49df9e3f3856ec0..df310d2a58cc6c30dfa6d2d8609149fbcf17ecca 100644
--- a/en/git-rerere.txt
+++ b/en/git-rerere.txt
@@ -205,12 +205,18 @@ development on the topic branch:
------------
you could run `git rebase master topic`, to bring yourself
-up-to-date before your topic is ready to be sent upstream.
+up to date before your topic is ready to be sent upstream.
This would result in falling back to a three-way merge, and it
would conflict the same way as the test merge you resolved earlier.
'git rerere' will be run by 'git rebase' to help you resolve this
conflict.
+[NOTE] 'git rerere' relies on the conflict markers in the file to
+detect the conflict. If the file already contains lines that look the
+same as lines with conflict markers, 'git rerere' may fail to record a
+conflict resolution. To work around this, the `conflict-marker-size`
+setting in linkgit:gitattributes[5] can be used.
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/en/git-reset.txt b/en/git-reset.txt
index 8a21198d65c77c4a23f95d089ed1ce7f003dc0c6..132f8e55f67b2e2a40f0058888f4f8260c51f270 100644
--- a/en/git-reset.txt
+++ b/en/git-reset.txt
@@ -14,14 +14,14 @@ SYNOPSIS
DESCRIPTION
-----------
-In the first and second form, copy entries from <tree-ish> to the index.
-In the third form, set the current branch head (HEAD) to <commit>, optionally
-modifying index and working tree to match. The <tree-ish>/<commit> defaults
-to HEAD in all forms.
+In the first and second form, copy entries from `<tree-ish>` to the index.
+In the third form, set the current branch head (`HEAD`) to `<commit>`,
+optionally modifying index and working tree to match.
+The `<tree-ish>`/`<commit>` defaults to `HEAD` in all forms.
'git reset' [-q] [<tree-ish>] [--] <paths>...::
- This form resets the index entries for all <paths> to their
- state at <tree-ish>. (It does not affect the working tree or
+ This form resets the index entries for all `<paths>` to their
+ state at `<tree-ish>`. (It does not affect the working tree or
the current branch.)
+
This means that `git reset <paths>` is the opposite of `git add
@@ -36,7 +36,7 @@ working tree in one go.
'git reset' (--patch | -p) [<tree-ish>] [--] [<paths>...]::
Interactively select hunks in the difference between the index
- and <tree-ish> (defaults to HEAD). The chosen hunks are applied
+ and `<tree-ish>` (defaults to `HEAD`). The chosen hunks are applied
in reverse to the index.
+
This means that `git reset -p` is the opposite of `git add -p`, i.e.
@@ -44,16 +44,16 @@ you can use it to selectively reset hunks. See the ``Interactive Mode''
section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
'git reset' [<mode>] [<commit>]::
- This form resets the current branch head to <commit> and
- possibly updates the index (resetting it to the tree of <commit>) and
- the working tree depending on <mode>. If <mode> is omitted,
- defaults to "--mixed". The <mode> must be one of the following:
+ This form resets the current branch head to `<commit>` and
+ possibly updates the index (resetting it to the tree of `<commit>`) and
+ the working tree depending on `<mode>`. If `<mode>` is omitted,
+ defaults to `--mixed`. The `<mode>` must be one of the following:
+
--
--soft::
Does not touch the index file or the working tree at all (but
- resets the head to <commit>, just like all modes do). This leaves
- all your changed files "Changes to be committed", as 'git status'
+ resets the head to `<commit>`, just like all modes do). This leaves
+ all your changed files "Changes to be committed", as `git status`
would put it.
--mixed::
@@ -66,24 +66,24 @@ linkgit:git-add[1]).
--hard::
Resets the index and working tree. Any changes to tracked files in the
- working tree since <commit> are discarded.
+ working tree since `<commit>` are discarded.
--merge::
Resets the index and updates the files in the working tree that are
- different between <commit> and HEAD, but keeps those which are
+ different between `<commit>` and `HEAD`, but keeps those which are
different between the index and working tree (i.e. which have changes
which have not been added).
- If a file that is different between <commit> and the index has unstaged
- changes, reset is aborted.
+ If a file that is different between `<commit>` and the index has
+ unstaged changes, reset is aborted.
+
-In other words, --merge does something like a 'git read-tree -u -m <commit>',
+In other words, `--merge` does something like a `git read-tree -u -m <commit>`,
but carries forward unmerged index entries.
--keep::
Resets index entries and updates files in the working tree that are
- different between <commit> and HEAD.
- If a file that is different between <commit> and HEAD has local changes,
- reset is aborted.
+ different between `<commit>` and `HEAD`.
+ If a file that is different between `<commit>` and `HEAD` has local
+ changes, reset is aborted.
--
If you want to undo a commit other than the latest on a branch,
@@ -95,7 +95,10 @@ OPTIONS
-q::
--quiet::
- Be quiet, only report errors.
+--no-quiet::
+ Be quiet, only report errors. The default behavior is set by the
+ `reset.quiet` config option. `--quiet` and `--no-quiet` will
+ override the default behavior.
EXAMPLES
@@ -112,17 +115,17 @@ $ git pull git://info.example.com/ nitfol <4>
------------
+
<1> You are happily working on something, and find the changes
-in these files are in good order. You do not want to see them
-when you run "git diff", because you plan to work on other files
-and changes with these files are distracting.
-<2> Somebody asks you to pull, and the changes sounds worthy of merging.
+ in these files are in good order. You do not want to see them
+ when you run `git diff`, because you plan to work on other files
+ and changes with these files are distracting.
+<2> Somebody asks you to pull, and the changes sound worthy of merging.
<3> However, you already dirtied the index (i.e. your index does
-not match the HEAD commit). But you know the pull you are going
-to make does not affect frotz.c or filfre.c, so you revert the
-index changes for these two files. Your changes in working tree
-remain there.
-<4> Then you can pull and merge, leaving frotz.c and filfre.c
-changes still in the working tree.
+ not match the `HEAD` commit). But you know the pull you are going
+ to make does not affect `frotz.c` or `filfre.c`, so you revert the
+ index changes for these two files. Your changes in working tree
+ remain there.
+<4> Then you can pull and merge, leaving `frotz.c` and `filfre.c`
+ changes still in the working tree.
Undo a commit and redo::
+
@@ -134,14 +137,14 @@ $ git commit -a -c ORIG_HEAD <3>
------------
+
<1> This is most often done when you remembered what you
-just committed is incomplete, or you misspelled your commit
-message, or both. Leaves working tree as it was before "reset".
+ just committed is incomplete, or you misspelled your commit
+ message, or both. Leaves working tree as it was before "reset".
<2> Make corrections to working tree files.
-<3> "reset" copies the old head to .git/ORIG_HEAD; redo the
-commit by starting with its log message. If you do not need to
-edit the message further, you can give -C option instead.
+<3> "reset" copies the old head to `.git/ORIG_HEAD`; redo the
+ commit by starting with its log message. If you do not need to
+ edit the message further, you can give `-C` option instead.
+
-See also the --amend option to linkgit:git-commit[1].
+See also the `--amend` option to linkgit:git-commit[1].
Undo a commit, making it a topic branch::
+
@@ -152,11 +155,11 @@ $ git checkout topic/wip <3>
------------
+
<1> You have made some commits, but realize they were premature
-to be in the "master" branch. You want to continue polishing
-them in a topic branch, so create "topic/wip" branch off of the
-current HEAD.
+ to be in the `master` branch. You want to continue polishing
+ them in a topic branch, so create `topic/wip` branch off of the
+ current `HEAD`.
<2> Rewind the master branch to get rid of those three commits.
-<3> Switch to "topic/wip" branch and keep working.
+<3> Switch to `topic/wip` branch and keep working.
Undo commits permanently::
+
@@ -165,11 +168,11 @@ $ git commit ...
$ git reset --hard HEAD~3 <1>
------------
+
-<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
-and you do not want to ever see them again. Do *not* do this if
-you have already given these commits to somebody else. (See the
-"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
-the implications of doing so.)
+<1> The last three commits (`HEAD`, `HEAD^`, and `HEAD~2`) were bad
+ and you do not want to ever see them again. Do *not* do this if
+ you have already given these commits to somebody else. (See the
+ "RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1]
+ for the implications of doing so.)
Undo a merge or pull::
+
@@ -186,18 +189,18 @@ $ git reset --hard ORIG_HEAD <4>
------------
+
<1> Try to update from the upstream resulted in a lot of
-conflicts; you were not ready to spend a lot of time merging
-right now, so you decide to do that later.
-<2> "pull" has not made merge commit, so "git reset --hard"
-which is a synonym for "git reset --hard HEAD" clears the mess
-from the index file and the working tree.
+ conflicts; you were not ready to spend a lot of time merging
+ right now, so you decide to do that later.
+<2> "pull" has not made merge commit, so `git reset --hard`
+ which is a synonym for `git reset --hard HEAD` clears the mess
+ from the index file and the working tree.
<3> Merge a topic branch into the current branch, which resulted
-in a fast-forward.
+ in a fast-forward.
<4> But you decided that the topic branch is not ready for public
-consumption yet. "pull" or "merge" always leaves the original
-tip of the current branch in ORIG_HEAD, so resetting hard to it
-brings your index file and the working tree back to that state,
-and resets the tip of the branch to that commit.
+ consumption yet. "pull" or "merge" always leaves the original
+ tip of the current branch in `ORIG_HEAD`, so resetting hard to it
+ brings your index file and the working tree back to that state,
+ and resets the tip of the branch to that commit.
Undo a merge or pull inside a dirty working tree::
+
@@ -211,14 +214,14 @@ $ git reset --merge ORIG_HEAD <2>
------------
+
<1> Even if you may have local modifications in your
-working tree, you can safely say "git pull" when you know
-that the change in the other branch does not overlap with
-them.
+ working tree, you can safely say `git pull` when you know
+ that the change in the other branch does not overlap with
+ them.
<2> After inspecting the result of the merge, you may find
-that the change in the other branch is unsatisfactory. Running
-"git reset --hard ORIG_HEAD" will let you go back to where you
-were, but it will discard your local changes, which you do not
-want. "git reset --merge" keeps your local changes.
+ that the change in the other branch is unsatisfactory. Running
+ `git reset --hard ORIG_HEAD` will let you go back to where you
+ were, but it will discard your local changes, which you do not
+ want. `git reset --merge` keeps your local changes.
Interrupted workflow::
@@ -284,17 +287,17 @@ $ git checkout -b branch2 <2>
$ git reset --keep start <3>
------------
+
-<1> This commits your first edits in branch1.
+<1> This commits your first edits in `branch1`.
<2> In the ideal world, you could have realized that the earlier
commit did not belong to the new topic when you created and switched
- to branch2 (i.e. "git checkout -b branch2 start"), but nobody is
+ to `branch2` (i.e. `git checkout -b branch2 start`), but nobody is
perfect.
-<3> But you can use "reset --keep" to remove the unwanted commit after
- you switched to "branch2".
+<3> But you can use `reset --keep` to remove the unwanted commit after
+ you switched to `branch2`.
Split a commit apart into a sequence of commits::
+
-Suppose that you have created lots of logically separate changes and commited
+Suppose that you have created lots of logically separate changes and committed
them together. Then, later you decide that it might be better to have each
logical chunk associated with its own commit. You can use git reset to rewind
history without changing the contents of your local files, and then successively
@@ -314,26 +317,27 @@ $ git commit ... <8>
+
<1> First, reset the history back one commit so that we remove the original
commit, but leave the working tree with all the changes. The -N ensures
- that any new files added with HEAD are still marked so that git add -p
+ that any new files added with `HEAD` are still marked so that `git add -p`
will find them.
-<2> Next, we interactively select diff hunks to add using the git add -p
+<2> Next, we interactively select diff hunks to add using the `git add -p`
facility. This will ask you about each diff hunk in sequence and you can
use simple commands such as "yes, include this", "No don't include this"
or even the very powerful "edit" facility.
<3> Once satisfied with the hunks you want to include, you should verify what
- has been prepared for the first commit by using git diff --cached. This
+ has been prepared for the first commit by using `git diff --cached`. This
shows all the changes that have been moved into the index and are about
to be committed.
-<4> Next, commit the changes stored in the index. The -c option specifies to
+<4> Next, commit the changes stored in the index. The `-c` option specifies to
pre-populate the commit message from the original message that you started
- with in the first commit. This is helpful to avoid retyping it. The HEAD@{1}
- is a special notation for the commit that HEAD used to be at prior to the
- original reset commit (1 change ago). See linkgit:git-reflog[1] for more
- details. You may also use any other valid commit reference.
+ with in the first commit. This is helpful to avoid retyping it. The
+ `HEAD@{1}` is a special notation for the commit that `HEAD` used to be at
+ prior to the original reset commit (1 change ago).
+ See linkgit:git-reflog[1] for more details. You may also use any other
+ valid commit reference.
<5> You can repeat steps 2-4 multiple times to break the original code into
any number of commits.
<6> Now you've split out many of the changes into their own commits, and might
- no longer use the patch mode of git add, in order to select all remaining
+ no longer use the patch mode of `git add`, in order to select all remaining
uncommitted changes.
<7> Once again, check to verify that you've included what you want to. You may
also wish to verify that git diff doesn't show any remaining changes to be
@@ -350,104 +354,120 @@ The tables below show what happens when running:
git reset --option target
----------
-to reset the HEAD to another commit (`target`) with the different
+to reset the `HEAD` to another commit (`target`) with the different
reset options depending on the state of the files.
-In these tables, A, B, C and D are some different states of a
+In these tables, `A`, `B`, `C` and `D` are some different states of a
file. For example, the first line of the first table means that if a
-file is in state A in the working tree, in state B in the index, in
-state C in HEAD and in state D in the target, then "git reset --soft
-target" will leave the file in the working tree in state A and in the
-index in state B. It resets (i.e. moves) the HEAD (i.e. the tip of
-the current branch, if you are on one) to "target" (which has the file
-in state D).
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- A B C D --soft A B D
- --mixed A D D
- --hard D D D
- --merge (disallowed)
- --keep (disallowed)
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- A B C C --soft A B C
- --mixed A C C
- --hard C C C
- --merge (disallowed)
- --keep A C C
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- B B C D --soft B B D
- --mixed B D D
- --hard D D D
- --merge D D D
- --keep (disallowed)
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- B B C C --soft B B C
- --mixed B C C
- --hard C C C
- --merge C C C
- --keep B C C
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- B C C D --soft B C D
- --mixed B D D
- --hard D D D
- --merge (disallowed)
- --keep (disallowed)
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- B C C C --soft B C C
- --mixed B C C
- --hard C C C
- --merge B C C
- --keep B C C
-
-"reset --merge" is meant to be used when resetting out of a conflicted
+file is in state `A` in the working tree, in state `B` in the index, in
+state `C` in `HEAD` and in state `D` in the target, then `git reset --soft
+target` will leave the file in the working tree in state `A` and in the
+index in state `B`. It resets (i.e. moves) the `HEAD` (i.e. the tip of
+the current branch, if you are on one) to `target` (which has the file
+in state `D`).
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ A B C D --soft A B D
+ --mixed A D D
+ --hard D D D
+ --merge (disallowed)
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ A B C C --soft A B C
+ --mixed A C C
+ --hard C C C
+ --merge (disallowed)
+ --keep A C C
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B B C D --soft B B D
+ --mixed B D D
+ --hard D D D
+ --merge D D D
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B B C C --soft B B C
+ --mixed B C C
+ --hard C C C
+ --merge C C C
+ --keep B C C
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B C C D --soft B C D
+ --mixed B D D
+ --hard D D D
+ --merge (disallowed)
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ B C C C --soft B C C
+ --mixed B C C
+ --hard C C C
+ --merge B C C
+ --keep B C C
+....
+
+`reset --merge` is meant to be used when resetting out of a conflicted
merge. Any mergy operation guarantees that the working tree file that is
involved in the merge does not have local change wrt the index before
it starts, and that it writes the result out to the working tree. So if
we see some difference between the index and the target and also
between the index and the working tree, then it means that we are not
resetting out from a state that a mergy operation left after failing
-with a conflict. That is why we disallow --merge option in this case.
+with a conflict. That is why we disallow `--merge` option in this case.
-"reset --keep" is meant to be used when removing some of the last
+`reset --keep` is meant to be used when removing some of the last
commits in the current branch while keeping changes in the working
tree. If there could be conflicts between the changes in the commit we
want to remove and the changes in the working tree we want to keep,
the reset is disallowed. That's why it is disallowed if there are both
-changes between the working tree and HEAD, and between HEAD and the
+changes between the working tree and `HEAD`, and between `HEAD` and the
target. To be safe, it is also disallowed when there are unmerged
entries.
The following tables show what happens when there are unmerged
entries:
- working index HEAD target working index HEAD
- ----------------------------------------------------
- X U A B --soft (disallowed)
- --mixed X B B
- --hard B B B
- --merge B B B
- --keep (disallowed)
-
- working index HEAD target working index HEAD
- ----------------------------------------------------
- X U A A --soft (disallowed)
- --mixed X A A
- --hard A A A
- --merge A A A
- --keep (disallowed)
-
-X means any state and U means an unmerged index.
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ X U A B --soft (disallowed)
+ --mixed X B B
+ --hard B B B
+ --merge B B B
+ --keep (disallowed)
+....
+
+....
+working index HEAD target working index HEAD
+----------------------------------------------------
+ X U A A --soft (disallowed)
+ --mixed X A A
+ --hard A A A
+ --merge A A A
+ --keep (disallowed)
+....
+
+`X` means any state and `U` means an unmerged index.
GIT
---
diff --git a/en/git-rev-list.txt b/en/git-rev-list.txt
index ef22f1775b634812a6d0595ca3d88ce0b0c51506..88609ff4351bb7793ffa0ce9f21efb39a8157da4 100644
--- a/en/git-rev-list.txt
+++ b/en/git-rev-list.txt
@@ -47,7 +47,9 @@ SYNOPSIS
[ --fixed-strings | -F ]
[ --date=<format>]
[ [ --objects | --objects-edge | --objects-edge-aggressive ]
- [ --unpacked ] ]
+ [ --unpacked ]
+ [ --filter=<filter-spec> [ --filter-print-omitted ] ] ]
+ [ --missing=<missing-action> ]
[ --pretty | --header ]
[ --bisect ]
[ --bisect-vars ]
diff --git a/en/git-rev-parse.txt b/en/git-rev-parse.txt
index c40c4704486dd9d1a5650562540db7379818ab03..e72d332b8316763d40e7bcfe0e32bcaa61842cf8 100644
--- a/en/git-rev-parse.txt
+++ b/en/git-rev-parse.txt
@@ -9,7 +9,7 @@ git-rev-parse - Pick out and massage parameters
SYNOPSIS
--------
[verse]
-'git rev-parse' [ --option ] <args>...
+'git rev-parse' [<options>] <args>...
DESCRIPTION
-----------
@@ -126,6 +126,12 @@ can be used.
'git diff-{asterisk}'). In contrast to the `--sq-quote` option,
the command input is still interpreted as usual.
+--short[=length]::
+ Same as `--verify` but shortens the object name to a unique
+ prefix with at least `length` characters. The minimum length
+ is 4, the default is the effective value of the `core.abbrev`
+ configuration variable (see linkgit:git-config[1]).
+
--not::
When showing object names, prefix them with '{caret}' and
strip '{caret}' prefix from the object names that already have
@@ -136,12 +142,6 @@ can be used.
The option core.warnAmbiguousRefs is used to select the strict
abbreviation mode.
---short::
---short=number::
- Instead of outputting the full SHA-1 values of object names try to
- abbreviate them to a shorter unique name. When no length is specified
- 7 is used. The minimum length is 4.
-
--symbolic::
Usually the object names are output in SHA-1 form (with
possible '{caret}' prefix); this option makes them output in a
@@ -235,6 +235,9 @@ print a message to stderr and exit with nonzero status.
--is-bare-repository::
When the repository is bare print "true", otherwise "false".
+--is-shallow-repository::
+ When the repository is shallow print "true", otherwise "false".
+
--resolve-git-dir <path>::
Check if <path> is a valid repository or a gitfile that
points at a valid repository, and print the location of the
@@ -261,7 +264,7 @@ print a message to stderr and exit with nonzero status.
--show-toplevel::
Show the absolute path of the top-level directory.
---show-superproject-working-tree
+--show-superproject-working-tree::
Show the absolute path of the root of the superproject's
working tree (if exists) that uses the current repository as
its submodule. Outputs nothing if the current repository is
@@ -357,7 +360,7 @@ Example
------------
OPTS_SPEC="\
-some-command [options] <args>...
+some-command [<options>] <args>...
some-command does foo and bar!
--
@@ -382,7 +385,7 @@ When `"$@"` is `-h` or `--help` in the above example, the following
usage text would be shown:
------------
-usage: some-command [options] <args>...
+usage: some-command [<options>] <args>...
some-command does foo and bar!
diff --git a/en/git-rm.txt b/en/git-rm.txt
index f1efc116ebb88a3bc31898f6a18837f8b951ad09..b5c46223c44b1b17673ae4782f74528b3d151bed 100644
--- a/en/git-rm.txt
+++ b/en/git-rm.txt
@@ -140,20 +140,21 @@ Only submodules using a gitfile (which means they were cloned
with a Git version 1.7.8 or newer) will be removed from the work
tree, as their repository lives inside the .git directory of the
superproject. If a submodule (or one of those nested inside it)
-still uses a .git directory, `git rm` will fail - no matter if forced
-or not - to protect the submodule's history. If it exists the
-submodule.<name> section in the linkgit:gitmodules[5] file will also
-be removed and that file will be staged (unless --cached or -n are used).
+still uses a .git directory, `git rm` will move the submodules
+git directory into the superprojects git directory to protect
+the submodule's history. If it exists the submodule.<name> section
+in the linkgit:gitmodules[5] file will also be removed and that file
+will be staged (unless --cached or -n are used).
-A submodule is considered up-to-date when the HEAD is the same as
+A submodule is considered up to date when the HEAD is the same as
recorded in the index, no tracked files are modified and no untracked
files that aren't ignored are present in the submodules work tree.
Ignored files are deemed expendable and won't stop a submodule's work
tree from being removed.
If you only want to remove the local checkout of a submodule from your
-work tree without committing the removal,
-use linkgit:git-submodule[1] `deinit` instead.
+work tree without committing the removal, use linkgit:git-submodule[1] `deinit`
+instead. Also see linkgit:gitsubmodules[7] for details on submodule removal.
EXAMPLES
--------
diff --git a/en/git-send-email.txt b/en/git-send-email.txt
index 9d66166f69d93e544c949ad80fe0f432fa3f1ffd..1afe9fc858ea7dcd05ae5f77c994af8f17f5bf52 100644
--- a/en/git-send-email.txt
+++ b/en/git-send-email.txt
@@ -9,7 +9,7 @@ git-send-email - Send a collection of patches as emails
SYNOPSIS
--------
[verse]
-'git send-email' [options] <file|directory|rev-list options>...
+'git send-email' [<options>] <file|directory|rev-list options>...
'git send-email' --dump-aliases
@@ -33,7 +33,7 @@ This is what linkgit:git-format-patch[1] generates. Most headers and MIME
formatting are ignored.
2. The original format used by Greg Kroah-Hartman's 'send_lots_of_email.pl'
-script
+ script
+
This format expects the first line of the file to contain the "Cc:" value
and the "Subject:" of the message as the second line.
@@ -84,6 +84,11 @@ See the CONFIGURATION section for `sendemail.multiEdit`.
the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not
set, as returned by "git var -l".
+--reply-to=<address>::
+ Specify the address where replies from recipients should go to.
+ Use this if replies to messages should go to another address than what
+ is specified with the --from parameter.
+
--in-reply-to=<identifier>::
Make the first mail (or all the mails with `--no-thread`) appear as a
reply to the given Message-Id, which avoids breaking threads to
@@ -132,15 +137,17 @@ Note that no attempts whatsoever are made to validate the encoding.
Specify encoding of compose message. Default is the value of the
'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed.
---transfer-encoding=(7bit|8bit|quoted-printable|base64)::
+--transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)::
Specify the transfer encoding to be used to send the message over SMTP.
7bit will fail upon encountering a non-ASCII message. quoted-printable
can be useful when the repository contains files that contain carriage
returns, but makes the raw patch email file (as saved from a MUA) much
harder to inspect manually. base64 is even more fool proof, but also
- even more opaque. Default is the value of the `sendemail.transferEncoding`
- configuration value; if that is unspecified, git will use 8bit and not
- add a Content-Transfer-Encoding header.
+ even more opaque. auto will use 8bit when possible, and quoted-printable
+ otherwise.
++
+Default is the value of the `sendemail.transferEncoding` configuration
+value; if that is unspecified, default to `auto`.
--xmailer::
--no-xmailer::
@@ -183,7 +190,9 @@ $ git send-email --smtp-auth="PLAIN LOGIN GSSAPI" ...
If at least one of the specified mechanisms matches the ones advertised by the
SMTP server and if it is supported by the utilized SASL library, the mechanism
is used for authentication. If neither 'sendemail.smtpAuth' nor `--smtp-auth`
-is specified, all mechanisms supported by the SASL library can be used.
+is specified, all mechanisms supported by the SASL library can be used. The
+special value 'none' maybe specified to completely disable authentication
+independently of `--smtp-user`
--smtp-pass[=<password>]::
Password for SMTP-AUTH. The argument is optional: If no
@@ -197,15 +206,18 @@ or on the command line. If a username has been specified (with
specified (with `--smtp-pass` or `sendemail.smtpPass`), then
a password is obtained using 'git-credential'.
+--no-smtp-auth::
+ Disable SMTP authentication. Short hand for `--smtp-auth=none`
+
--smtp-server=<host>::
If set, specifies the outgoing SMTP server to use (e.g.
`smtp.example.com` or a raw IP address). Alternatively it can
specify a full pathname of a sendmail-like program instead;
the program must support the `-i` option. Default value can
be specified by the `sendemail.smtpServer` configuration
- option; the built-in default is `/usr/sbin/sendmail` or
- `/usr/lib/sendmail` if such program is available, or
- `localhost` otherwise.
+ option; the built-in default is to search for `sendmail` in
+ `/usr/sbin`, `/usr/lib` and $PATH if such program is
+ available, falling back to `localhost` otherwise.
--smtp-server-port=<port>::
Specifies a port different from the default port (SMTP
@@ -248,6 +260,21 @@ must be used for each option.
commands and replies will be printed. Useful to debug TLS
connection and authentication problems.
+--batch-size=<num>::
+ Some email servers (e.g. smtp.163.com) limit the number emails to be
+ sent per session (connection) and this will lead to a failure when
+ sending many messages. With this option, send-email will disconnect after
+ sending $<num> messages and wait for a few seconds (see --relogin-delay)
+ and reconnect, to work around such a limit. You may want to
+ use some form of credential helper to avoid having to retype
+ your password every time this happens. Defaults to the
+ `sendemail.smtpBatchSize` configuration variable.
+
+--relogin-delay=<int>::
+ Waiting $<int> seconds before reconnecting to SMTP server. Used together
+ with --batch-size option. Defaults to the `sendemail.smtpReloginDelay`
+ configuration variable.
+
Automating
~~~~~~~~~~
@@ -299,16 +326,19 @@ Automating
auto-cc of:
+
--
-- 'author' will avoid including the patch author
-- 'self' will avoid including the sender
+- 'author' will avoid including the patch author.
+- 'self' will avoid including the sender.
- 'cc' will avoid including anyone mentioned in Cc lines in the patch header
except for self (use 'self' for that).
- 'bodycc' will avoid including anyone mentioned in Cc lines in the
patch body (commit message) except for self (use 'self' for that).
- 'sob' will avoid including anyone mentioned in Signed-off-by lines except
- for self (use 'self' for that).
+ for self (use 'self' for that).
+- 'misc-by' will avoid including anyone mentioned in Acked-by,
+ Reviewed-by, Tested-by and other "-by" lines in the patch body,
+ except Signed-off-by (use 'sob' for that).
- 'cccmd' will avoid running the --cc-cmd.
-- 'body' is equivalent to 'sob' + 'bodycc'
+- 'body' is equivalent to 'sob' + 'bodycc' + 'misc-by'.
- 'all' will suppress all auto cc values.
--
+
@@ -377,8 +407,12 @@ have been specified, in which case default to 'compose'.
Currently, validation means the following:
+
--
- * Warn of patches that contain lines longer than 998 characters; this
- is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
+ * Invoke the sendemail-validate hook if present (see linkgit:githooks[5]).
+ * Warn of patches that contain lines longer than
+ 998 characters unless a suitable transfer encoding
+ ('auto', 'base64', or 'quoted-printable') is used;
+ this is due to SMTP limits as described by
+ http://www.ietf.org/rfc/rfc5322.txt.
--
+
Default is the value of `sendemail.validate`; if this is not set,
@@ -437,8 +471,8 @@ sendemail.confirm::
one of 'always', 'never', 'cc', 'compose', or 'auto'. See `--confirm`
in the previous section for the meaning of these values.
-EXAMPLE
--------
+EXAMPLES
+--------
Use gmail as the smtp server
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To use 'git send-email' to send your patches through the GMail SMTP server,
@@ -452,16 +486,7 @@ edit ~/.gitconfig to specify your account settings:
If you have multifactor authentication setup on your gmail account, you will
need to generate an app-specific password for use with 'git send-email'. Visit
-https://security.google.com/settings/security/apppasswords to setup an
-app-specific password. Once setup, you can store it with the credentials
-helper:
-
- $ git credential fill
- protocol=smtp
- host=smtp.gmail.com
- username=youname@gmail.com
- password=app-password
-
+https://security.google.com/settings/security/apppasswords to create it.
Once your commits are ready to be sent to the mailing list, run the
following commands:
@@ -470,6 +495,11 @@ following commands:
$ edit outgoing/0000-*
$ git send-email outgoing/*
+The first time you run it, you will be prompted for your credentials. Enter the
+app-specific or your regular password as appropriate. If you have credential
+helper configured (see linkgit:git-credential[1]), the password will be saved in
+the credential store so you won't have to type it the next time.
+
Note: the following perl modules are required
Net::SMTP::SSL, MIME::Base64 and Authen::SASL
diff --git a/en/git-send-pack.txt b/en/git-send-pack.txt
index a831dd0288306d3355bb5607bc6f36229563c8f7..44fd146b9120305112c59b800c9e989bbc60f450 100644
--- a/en/git-send-pack.txt
+++ b/en/git-send-pack.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>]
[--verbose] [--thin] [--atomic]
- [--[no-]signed|--sign=(true|false|if-asked)]
+ [--[no-]signed|--signed=(true|false|if-asked)]
[<host>:]<directory> [<ref>...]
DESCRIPTION
@@ -71,7 +71,7 @@ be in a separate packet, and the list must end with a flush packet.
refs.
--[no-]signed::
---sign=(true|false|if-asked)::
+--signed=(true|false|if-asked)::
GPG-sign the push request to update refs on the receiving
side, to allow it to be checked by the hooks and/or be
logged. If `false` or `--no-signed`, no signing will be
@@ -81,6 +81,12 @@ be in a separate packet, and the list must end with a flush packet.
will also fail if the actual call to `gpg --sign` fails. See
linkgit:git-receive-pack[1] for the details on the receiving end.
+--push-option=<string>::
+ Pass the specified string as a push option for consumption by
+ hooks on the server side. If the server doesn't support push
+ options, error out. See linkgit:git-push[1] and
+ linkgit:githooks[5] for details.
+
<host>::
A remote host to house the repository. When this
part is specified, 'git-receive-pack' is invoked via
@@ -93,7 +99,7 @@ be in a separate packet, and the list must end with a flush packet.
The remote refs to update.
-Specifying the Refs
+SPECIFYING THE REFS
-------------------
There are three ways to specify which refs to update on the
diff --git a/en/git-shell.txt b/en/git-shell.txt
index 2e30a3e42d4e4e2bab580b0dcb5701ca3b33aeed..11361f33e93937429a8d1791efaca5e00888f236 100644
--- a/en/git-shell.txt
+++ b/en/git-shell.txt
@@ -62,8 +62,8 @@ permissions.
If a `no-interactive-login` command exists, then it is run and the
interactive shell is aborted.
-EXAMPLE
--------
+EXAMPLES
+--------
To disable interactive logins, displaying a greeting instead:
@@ -79,6 +79,22 @@ EOF
$ chmod +x $HOME/git-shell-commands/no-interactive-login
----------------
+To enable git-cvsserver access (which should generally have the
+`no-interactive-login` example above as a prerequisite, as creating
+the git-shell-commands directory allows interactive logins):
+
+----------------
+$ cat >$HOME/git-shell-commands/cvs <<\EOF
+if ! test $# = 1 && test "$1" = "server"
+then
+ echo >&2 "git-cvsserver only handles \"server\""
+ exit 1
+fi
+exec git cvsserver server
+EOF
+$ chmod +x $HOME/git-shell-commands/cvs
+----------------
+
SEE ALSO
--------
ssh(1),
diff --git a/en/git-shortlog.txt b/en/git-shortlog.txt
index ee6c5476c1d2bf3b2a708e6152ebaba5882cc4f7..bc80905a8a06b5121e2c33c83844301a8212c28c 100644
--- a/en/git-shortlog.txt
+++ b/en/git-shortlog.txt
@@ -8,8 +8,8 @@ git-shortlog - Summarize 'git log' output
SYNOPSIS
--------
[verse]
+'git shortlog' [<options>] [<revision range>] [[--] <path>...]
git log --pretty=short | 'git shortlog' [<options>]
-'git shortlog' [<options>] [<revision range>] [[\--] <path>...]
DESCRIPTION
-----------
@@ -69,11 +69,11 @@ them.
ways to spell <revision range>, see the "Specifying Ranges"
section of linkgit:gitrevisions[7].
-[\--] <path>...::
+[--] <path>...::
Consider only commits that are enough to explain how the files
that match the specified paths came to be.
+
-Paths may need to be prefixed with "\-- " to separate them from
+Paths may need to be prefixed with `--` to separate them from
options or the revision range, when confusion arises.
MAPPING AUTHORS
diff --git a/en/git-show-branch.txt b/en/git-show-branch.txt
index 7818e0f09853f9c2a2ad0923d1fc13b698cad065..4a013712274f81d4ca594b06ae897db9e67ee827 100644
--- a/en/git-show-branch.txt
+++ b/en/git-show-branch.txt
@@ -19,7 +19,7 @@ DESCRIPTION
-----------
Shows the commit ancestry graph starting from the commits named
-with <rev>s or <globs>s (or all refs under refs/heads
+with <rev>s or <glob>s (or all refs under refs/heads
and/or refs/tags) semi-visually.
It cannot show more than 29 branches and commits at a time.
@@ -173,8 +173,8 @@ The "fixes" branch adds one commit "Introduce "reset type" flag to
The current branch is "master".
-EXAMPLE
--------
+EXAMPLES
+--------
If you keep your primary branches immediately under
`refs/heads`, and topic branches in subdirectories of
diff --git a/en/git-show-index.txt b/en/git-show-index.txt
index a8a9509e0eb0bb416ce0a32f76c964a505da8f61..424e4ba84cf9b0444a41f0a163de0a58a6ac378a 100644
--- a/en/git-show-index.txt
+++ b/en/git-show-index.txt
@@ -14,13 +14,27 @@ SYNOPSIS
DESCRIPTION
-----------
-Read the idx file for a Git packfile created with
-'git pack-objects' command from the standard input, and
-dump its contents.
+Read the `.idx` file for a Git packfile (created with
+linkgit:git-pack-objects[1] or linkgit:git-index-pack[1]) from the
+standard input, and dump its contents. The output consists of one object
+per line, with each line containing two or three space-separated
+columns:
-The information it outputs is subset of what you can get from
-'git verify-pack -v'; this command only shows the packfile
-offset and SHA-1 of each object.
+ - the first column is the offset in bytes of the object within the
+ corresponding packfile
+
+ - the second column is the object id of the object
+
+ - if the index version is 2 or higher, the third column contains the
+ CRC32 of the object data
+
+The objects are output in the order in which they are found in the index
+file, which should be (in a correctly constructed file) sorted by object
+id.
+
+Note that you can get more information on a packfile by calling
+linkgit:git-verify-pack[1]. However, as this command considers only the
+index file itself, it's both faster and more flexible.
GIT
---
diff --git a/en/git-show-ref.txt b/en/git-show-ref.txt
index c0aa871c9e8b06ea297e0a723167767338081453..ab4d271925da7983b16867d89e898bbed17ae469 100644
--- a/en/git-show-ref.txt
+++ b/en/git-show-ref.txt
@@ -37,8 +37,8 @@ OPTIONS
Show the HEAD reference, even if it would normally be filtered out.
---tags::
--heads::
+--tags::
Limit to "refs/heads" and "refs/tags", respectively. These options
are not mutually exclusive; when given both, references stored in
@@ -120,8 +120,8 @@ $ git show-ref --heads --hash
...
-----------------------------------------------------------------------------
-EXAMPLE
--------
+EXAMPLES
+--------
To show all references called "master", whether tags or heads or anything
else, and regardless of how deep in the reference naming hierarchy they are,
diff --git a/en/git-show.txt b/en/git-show.txt
index 82a4125a2da805e0b3c21e4e827bf203d5ac4532..fcf528c1b30d8045592d117ccc3d5f9248d0edbd 100644
--- a/en/git-show.txt
+++ b/en/git-show.txt
@@ -9,7 +9,7 @@ git-show - Show various types of objects
SYNOPSIS
--------
[verse]
-'git show' [options] <object>...
+'git show' [<options>] [<object>...]
DESCRIPTION
-----------
@@ -35,7 +35,7 @@ This manual page describes only the most frequently used options.
OPTIONS
-------
<object>...::
- The names of objects to show.
+ The names of objects to show (defaults to 'HEAD').
For a more complete list of ways to spell object names, see
"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
@@ -77,7 +77,7 @@ EXAMPLES
Concatenates the contents of said Makefiles in the head
of the branch `master`.
-Discussion
+DISCUSSION
----------
include::i18n.txt[]
diff --git a/en/git-stash.txt b/en/git-stash.txt
index 70191d06b69ed307c6ce1d8f46c158b61eb6545f..7ef8c4791177b2b54c61573c044659fbbacea9b8 100644
--- a/en/git-stash.txt
+++ b/en/git-stash.txt
@@ -13,10 +13,8 @@ SYNOPSIS
'git stash' drop [-q|--quiet] [<stash>]
'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>]
'git stash' branch <branchname> [<stash>]
-'git stash' save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
- [-u|--include-untracked] [-a|--all] [<message>]
'git stash' [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
- [-u|--include-untracked] [-a|--all] [-m|--message <message>]]
+ [-u|--include-untracked] [-a|--all] [-m|--message <message>]
[--] [<pathspec>...]]
'git stash' clear
'git stash' create [<message>]
@@ -33,7 +31,7 @@ and reverts the working directory to match the `HEAD` commit.
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 save`.
+Calling `git stash` without any arguments is equivalent to `git stash push`.
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.
@@ -48,21 +46,20 @@ stash index (e.g. the integer `n` is equivalent to `stash@{n}`).
OPTIONS
-------
-save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]::
push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [-m|--message <message>] [--] [<pathspec>...]::
- Save your local modifications to a new 'stash' and roll them
+ 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
the description along with the stashed state.
+
For quickly making a snapshot, you can omit "push". In this mode,
non-option arguments are not allowed to prevent a misspelled
-subcommand from making an unwanted stash. The two exceptions to this
+subcommand from making an unwanted stash entry. The two exceptions to this
are `stash -p` which acts as alias for `stash push -p` and pathspecs,
which are allowed after a double hyphen `--` for disambiguation.
+
-When pathspec is given to 'git stash push', the new stash records the
+When pathspec is given to 'git stash push', the new stash entry records the
modified states only for the files that match the pathspec. The index
entries and working tree files are then rolled back to the state in
HEAD only for these files, too, leaving files that do not match the
@@ -87,12 +84,18 @@ linkgit:git-add[1] to learn how to operate the `--patch` mode.
The `--patch` option implies `--keep-index`. You can use
`--no-keep-index` to override this.
+save [-p|--patch] [-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 pathspecs,
+ and any non-option arguments form the message.
+
list [<options>]::
- List the stashes that you currently have. Each 'stash' is listed
- with its name (e.g. `stash@{0}` is the latest stash, `stash@{1}` is
+ 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
the one before, etc.), the name of the branch that was current when the
- stash was made, and a short description of the commit the stash was
+ entry was made, and a short description of the commit the entry was
based on.
+
----------------------------------------------------------------
@@ -105,11 +108,12 @@ command to control what is shown and how. See linkgit:git-log[1].
show [<stash>]::
- Show the changes recorded in the stash as a diff between the
- stashed state and its original parent. When no `<stash>` is given,
- shows the latest one. 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 stash in patch form).
+ 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
+ created. When no `<stash>` is given, it shows the latest one.
+ 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).
You can use stash.showStat and/or stash.showPatch config variables
to change the default behavior.
@@ -117,7 +121,7 @@ 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
- operation of `git stash save`. The working directory must
+ operation of `git stash push`. The working directory must
match the index.
+
Applying the state can fail with conflicts; in this case, it is not
@@ -136,7 +140,7 @@ 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 save` or `stash create`.
+ `stash push` or `stash create`.
branch <branchname> [<stash>]::
@@ -147,45 +151,46 @@ branch <branchname> [<stash>]::
`stash@{<revision>}`, it then drops the `<stash>`. When no `<stash>`
is given, applies the latest one.
+
-This is useful if the branch on which you ran `git stash save` has
+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
-the stash 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.
+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::
- Remove all the stashed states. Note that those states will then
+ 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>]::
- Remove a single stashed state from the stash list. When no `<stash>`
- is given, it removes the latest one. i.e. `stash@{0}`, otherwise
- `<stash>` must be a valid stash log reference of the form
- `stash@{<revision>}`.
+ Remove a single stash entry from the list of stash entries.
+ When no `<stash>` is given, it removes the latest one.
+ i.e. `stash@{0}`, otherwise `<stash>` must be a valid stash
+ log reference of the form `stash@{<revision>}`.
create::
- Create a stash (which is a regular commit object) and return its
- object name, without storing it anywhere in the ref namespace.
+ 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 "save" above.
+ the command you want to use; see "push" above.
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 "save" above.
+ probably not the command you want to use; see "push" above.
DISCUSSION
----------
-A stash is represented as a commit whose tree records the state of the
-working directory, and its first parent is the commit at `HEAD` when
-the stash was created. The tree of the second parent records the
-state of the index when the stash is made, and it is made a child of
+A stash entry is represented as a commit whose tree records the state
+of the working directory, and its first parent is the commit at `HEAD`
+when the entry was created. The tree of the second parent records the
+state of the index when the entry is made, and it is made a child of
the `HEAD` commit. The ancestry graph looks like this:
.----W
@@ -253,14 +258,14 @@ $ git stash pop
Testing partial commits::
-You can use `git stash save --keep-index` when you want to make two or
+You can use `git stash push --keep-index` when you want to make two or
more commits out of the changes in the work tree, and you want to test
each change before committing:
+
----------------------------------------------------------------
# ... hack hack hack ...
$ git add --patch foo # add just first part to the index
-$ git stash save --keep-index # save all other changes to the stash
+$ git stash push --keep-index # save all other changes to the stash
$ edit/build/test first part
$ git commit -m 'First part' # commit fully tested change
$ git stash pop # prepare to work on all other changes
@@ -269,12 +274,12 @@ $ edit/build/test remaining parts
$ git commit foo -m 'Remaining parts'
----------------------------------------------------------------
-Recovering stashes that were cleared/dropped erroneously::
+Recovering stash entries that were cleared/dropped erroneously::
-If you mistakenly drop or clear stashes, they cannot be recovered
+If you mistakenly drop or clear stash entries, they cannot be recovered
through the normal safety mechanisms. However, you can try the
-following incantation to get a list of stashes that are still in your
-repository, but not reachable any more:
+following incantation to get a list of stash entries that are still in
+your repository, but not reachable any more:
+
----------------------------------------------------------------
git fsck --unreachable |
diff --git a/en/git-status.txt b/en/git-status.txt
index ba873657cf2f9d139d2ddb7c19e6865cc159a64d..861d821d7f26ec88818008f4c6825bfcad2590ce 100644
--- a/en/git-status.txt
+++ b/en/git-status.txt
@@ -32,6 +32,9 @@ OPTIONS
--branch::
Show the branch and tracking info even in short-format.
+--show-stash::
+ Show the number of entries currently stashed away.
+
--porcelain[=<version>]::
Give the output in an easy-to-parse format for scripts.
This is similar to the short output, but will remain stable
@@ -94,8 +97,27 @@ configuration variable documented in linkgit:git-config[1].
(and suppresses the output of submodule summaries when the config option
`status.submoduleSummary` is set).
---ignored::
+--ignored[=<mode>]::
Show ignored files as well.
++
+The mode parameter is used to specify the handling of ignored files.
+It is optional: it defaults to 'traditional'.
++
+The possible options are:
++
+ - 'traditional' - Shows ignored files and directories, unless
+ --untracked-files=all is specified, in which case
+ individual files in ignored directories are
+ displayed.
+ - 'no' - Show no ignored files.
+ - 'matching' - Shows ignored files and directories matching an
+ ignore pattern.
++
+When 'matching' mode is specified, paths that explicitly match an
+ignored pattern are shown. If a directory matches an ignore pattern,
+then it is shown, but not paths contained in the ignored directory. If
+a directory does not match an ignore pattern, but all contents are
+ignored, then the directory is not shown, but all contents are shown.
-z::
Terminate entries with NUL, instead of LF. This implies
@@ -108,6 +130,23 @@ configuration variable documented in linkgit:git-config[1].
without options are equivalent to 'always' and 'never'
respectively.
+--ahead-behind::
+--no-ahead-behind::
+ Display or do not display detailed ahead/behind counts for the
+ branch relative to its upstream branch. Defaults to true.
+
+--renames::
+--no-renames::
+ Turn on/off rename detection regardless of user configuration.
+ See also linkgit:git-diff[1] `--no-renames`.
+
+--find-renames[=<n>]::
+ Turn on rename detection, optionally setting the similarity
+ threshold.
+ See also linkgit:git-diff[1] `--find-renames`.
+
+<pathspec>...::
+ See the 'pathspec' entry in linkgit:gitglossary[7].
OUTPUT
------
@@ -125,14 +164,15 @@ the status.relativePaths config option below.
Short Format
~~~~~~~~~~~~
-In the short-format, the status of each path is shown as
+In the short-format, the status of each path is shown as one of these
+forms
- XY PATH1 -> PATH2
+ XY PATH
+ XY ORIG_PATH -> PATH
-where `PATH1` is the path in the `HEAD`, and the " `-> PATH2`" part is
-shown only when `PATH1` corresponds to a different path in the
-index/worktree (i.e. the file is renamed). The `XY` is a two-letter
-status code.
+where `ORIG_PATH` is where the renamed/copied contents came
+from. `ORIG_PATH` is only shown when the entry is renamed or
+copied. The `XY` is a two-letter status code.
The fields (including the `->`) are separated from each other by a
single space. If a filename contains whitespace or other nonprintable
@@ -157,29 +197,44 @@ codes can be interpreted as follows:
Ignored files are not listed, unless `--ignored` option is in effect,
in which case `XY` are `!!`.
- X Y Meaning
- -------------------------------------------------
- [MD] not updated
- M [ MD] updated in index
- A [ MD] added to index
- D [ M] deleted from index
- R [ MD] renamed in index
- C [ MD] copied in index
- [MARC] index and work tree matches
- [ MARC] M work tree changed since index
- [ MARC] D deleted in work tree
- -------------------------------------------------
- D D unmerged, both deleted
- A U unmerged, added by us
- U D unmerged, deleted by them
- U A unmerged, added by them
- D U unmerged, deleted by us
- A A unmerged, both added
- U U unmerged, both modified
- -------------------------------------------------
- ? ? untracked
- ! ! ignored
- -------------------------------------------------
+....
+X Y Meaning
+-------------------------------------------------
+ [AMD] not updated
+M [ MD] updated in index
+A [ MD] added to index
+D deleted from index
+R [ MD] renamed in index
+C [ MD] copied in index
+[MARC] index and work tree matches
+[ MARC] M work tree changed since index
+[ MARC] D deleted in work tree
+[ D] R renamed in work tree
+[ D] C copied in work tree
+-------------------------------------------------
+D D unmerged, both deleted
+A U unmerged, added by us
+U D unmerged, deleted by them
+U A unmerged, added by them
+D U unmerged, deleted by us
+A A unmerged, both added
+U U unmerged, both modified
+-------------------------------------------------
+? ? untracked
+! ! ignored
+-------------------------------------------------
+....
+
+Submodules have more state and instead report
+ M the submodule has a different HEAD than
+ recorded in the index
+ m the submodule has modified content
+ ? the submodule has untracked files
+since modified content or untracked files in a submodule cannot be added
+via `git add` in the superproject to prepare a commit.
+
+'m' and '?' are applied recursively. For example if a nested submodule
+in a submodule contains an untracked file, this is reported as '?' as well.
If -b is used the short-format status is preceded by a line
@@ -210,6 +265,8 @@ field from the first filename). Third, filenames containing special
characters are not specially formatted; no quoting or
backslash-escaping is performed.
+Any submodule changes are reported as modified `M` instead of `m` or single `?`.
+
Porcelain Format Version 2
~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -226,14 +283,16 @@ don't recognize.
If `--branch` is given, a series of header lines are printed with
information about the current branch.
- Line Notes
- ------------------------------------------------------------
- # branch.oid <commit> | (initial) Current commit.
- # branch.head <branch> | (detached) Current branch.
- # branch.upstream <upstream_branch> If upstream is set.
- # branch.ab +<ahead> -<behind> If upstream is set and
- the commit is present.
- ------------------------------------------------------------
+....
+Line Notes
+------------------------------------------------------------
+# branch.oid <commit> | (initial) Current commit.
+# branch.head <branch> | (detached) Current branch.
+# branch.upstream <upstream_branch> If upstream is set.
+# branch.ab +<ahead> -<behind> If upstream is set and
+ the commit is present.
+------------------------------------------------------------
+....
### Changed Tracked Entries
@@ -251,56 +310,60 @@ Renamed or copied entries have the following format:
2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>
- Field Meaning
- --------------------------------------------------------
- <XY> A 2 character field containing the staged and
- unstaged XY values described in the short format,
- with unchanged indicated by a "." rather than
- a space.
- <sub> A 4 character field describing the submodule state.
- "N..." when the entry is not a submodule.
- "S<c><m><u>" when the entry is a submodule.
- <c> is "C" if the commit changed; otherwise ".".
- <m> is "M" if it has tracked changes; otherwise ".".
- <u> is "U" if there are untracked changes; otherwise ".".
- <mH> The octal file mode in HEAD.
- <mI> The octal file mode in the index.
- <mW> The octal file mode in the worktree.
- <hH> The object name in HEAD.
- <hI> The object name in the index.
- <X><score> The rename or copy score (denoting the percentage
- of similarity between the source and target of the
- move or copy). For example "R100" or "C75".
- <path> The pathname. In a renamed/copied entry, this
- is the path in the index and in the working tree.
- <sep> When the `-z` option is used, the 2 pathnames are separated
- with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
- byte separates them.
- <origPath> The pathname in the commit at HEAD. This is only
- present in a renamed/copied entry, and tells
- where the renamed/copied contents came from.
- --------------------------------------------------------
+....
+Field Meaning
+--------------------------------------------------------
+<XY> A 2 character field containing the staged and
+ unstaged XY values described in the short format,
+ with unchanged indicated by a "." rather than
+ a space.
+<sub> A 4 character field describing the submodule state.
+ "N..." when the entry is not a submodule.
+ "S<c><m><u>" when the entry is a submodule.
+ <c> is "C" if the commit changed; otherwise ".".
+ <m> is "M" if it has tracked changes; otherwise ".".
+ <u> is "U" if there are untracked changes; otherwise ".".
+<mH> The octal file mode in HEAD.
+<mI> The octal file mode in the index.
+<mW> The octal file mode in the worktree.
+<hH> The object name in HEAD.
+<hI> The object name in the index.
+<X><score> The rename or copy score (denoting the percentage
+ of similarity between the source and target of the
+ move or copy). For example "R100" or "C75".
+<path> The pathname. In a renamed/copied entry, this
+ is the target path.
+<sep> When the `-z` option is used, the 2 pathnames are separated
+ with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
+ byte separates them.
+<origPath> The pathname in the commit at HEAD or in the index.
+ This is only present in a renamed/copied entry, and
+ tells where the renamed/copied contents came from.
+--------------------------------------------------------
+....
Unmerged entries have the following format; the first character is
a "u" to distinguish from ordinary changed entries.
u <xy> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>
- Field Meaning
- --------------------------------------------------------
- <XY> A 2 character field describing the conflict type
- as described in the short format.
- <sub> A 4 character field describing the submodule state
- as described above.
- <m1> The octal file mode in stage 1.
- <m2> The octal file mode in stage 2.
- <m3> The octal file mode in stage 3.
- <mW> The octal file mode in the worktree.
- <h1> The object name in stage 1.
- <h2> The object name in stage 2.
- <h3> The object name in stage 3.
- <path> The pathname.
- --------------------------------------------------------
+....
+Field Meaning
+--------------------------------------------------------
+<XY> A 2 character field describing the conflict type
+ as described in the short format.
+<sub> A 4 character field describing the submodule state
+ as described above.
+<m1> The octal file mode in stage 1.
+<m2> The octal file mode in stage 2.
+<m3> The octal file mode in stage 3.
+<mW> The octal file mode in the worktree.
+<h1> The object name in stage 1.
+<h2> The object name in stage 2.
+<h3> The object name in stage 3.
+<path> The pathname.
+--------------------------------------------------------
+....
### Other Items
@@ -350,6 +413,19 @@ ignored submodules you can either use the --ignore-submodules=dirty command
line option or the 'git submodule summary' command, which shows a similar
output but does not honor these settings.
+BACKGROUND REFRESH
+------------------
+
+By default, `git status` will automatically refresh the index, updating
+the cached stat information from the working tree and writing out the
+result. Writing out the updated index is an optimization that isn't
+strictly necessary (`status` computes the values for itself, but writing
+them out is just to save subsequent programs from repeating our
+computation). When `status` is run in the background, the lock held
+during the write may conflict with other simultaneous processes, causing
+them to fail. Scripts running `status` in the background should consider
+using `git --no-optional-locks status` (see linkgit:git[1] for details).
+
SEE ALSO
--------
linkgit:gitignore[5]
diff --git a/en/git-submodule.txt b/en/git-submodule.txt
index e05d0cddefe16194f87b00918f057bf4fb481855..ba3c4df550acfeb04a0a6b753a778816f031492c 100644
--- a/en/git-submodule.txt
+++ b/en/git-submodule.txt
@@ -24,37 +24,7 @@ DESCRIPTION
-----------
Inspects, updates and manages submodules.
-A submodule allows you to keep another Git repository in a subdirectory
-of your repository. The other repository has its own history, which does not
-interfere with the history of the current repository. This can be used to
-have external dependencies such as third party libraries for example.
-
-When cloning or pulling a repository containing submodules however,
-these will not be checked out by default; the 'init' and 'update'
-subcommands will maintain submodules checked out and at
-appropriate revision in your working tree.
-
-Submodules are composed from a so-called `gitlink` tree entry
-in the main repository that refers to a particular commit object
-within the inner repository that is completely separate.
-A record in the `.gitmodules` (see linkgit:gitmodules[5]) file at the
-root of the source tree assigns a logical name to the submodule and
-describes the default URL the submodule shall be cloned from.
-The logical name can be used for overriding this URL within your
-local repository configuration (see 'submodule init').
-
-Submodules are not to be confused with remotes, which are other
-repositories of the same project; submodules are meant for
-different projects you would like to make part of your source tree,
-while the history of the two projects still stays completely
-independent and you cannot modify the contents of the submodule
-from within the main project.
-If you want to merge the project histories and want to treat the
-aggregated whole as a single project from then on, you may want to
-add a remote for the other project and use the 'subtree' merge strategy,
-instead of treating the other project as a submodule. Directories
-that come from both projects can be cloned and checked out as a whole
-if you choose to go that route.
+For more information about submodules, see linkgit:gitsubmodules[7].
COMMANDS
--------
@@ -63,14 +33,6 @@ add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--dep
to the changeset to be committed next to the current
project: the current project is termed the "superproject".
+
-This requires at least one argument: <repository>. The optional
-argument <path> is the relative location for the cloned submodule
-to exist in the superproject. If <path> is not given, the
-"humanish" part of the source repository is used ("repo" for
-"/path/to/repo.git" and "foo" for "host.xz:foo/.git").
-The <path> is also used as the submodule's logical name in its
-configuration entries unless `--name` is used to specify a logical name.
-+
<repository> is the URL of the new submodule's origin repository.
This may be either an absolute URL, or (if it begins with ./
or ../), the location relative to the superproject's default remote
@@ -80,35 +42,36 @@ have to use '../foo.git' instead of './foo.git' - as one might expect
when following the rules for relative URLs - because the evaluation
of relative URLs in Git is identical to that of relative directories).
+
-The default remote is the remote of the remote tracking branch
-of the current branch. If no such remote tracking branch exists or
+The default remote is the remote of the remote-tracking branch
+of the current branch. If no such remote-tracking branch exists or
the HEAD is detached, "origin" is assumed to be the default remote.
If the superproject doesn't have a default remote configured
the superproject is its own authoritative upstream and the current
working directory is used instead.
+
-<path> is the relative location for the cloned submodule to
-exist in the superproject. If <path> does not exist, then the
-submodule is created by cloning from the named URL. If <path> does
-exist and is already a valid Git repository, then this is added
-to the changeset without cloning. This second form is provided
-to ease creating a new submodule from scratch, and presumes
-the user will later push the submodule to the given URL.
+The optional argument <path> is the relative location for the cloned
+submodule to exist in the superproject. If <path> is not given, the
+canonical part of the source repository is used ("repo" for
+"/path/to/repo.git" and "foo" for "host.xz:foo/.git"). If <path>
+exists and is already a valid Git repository, then it is staged
+for commit without cloning. The <path> is also used as the submodule's
+logical name in its configuration entries unless `--name` is used
+to specify a logical name.
+
-In either case, the given URL is recorded into .gitmodules for
-use by subsequent users cloning the superproject. If the URL is
-given relative to the superproject's repository, the presumption
-is the superproject and submodule repositories will be kept
-together in the same relative location, and only the
-superproject's URL needs to be provided: git-submodule will correctly
-locate the submodule using the relative URL in .gitmodules.
+The given URL is recorded into `.gitmodules` for use by subsequent users
+cloning the superproject. If the URL is given relative to the
+superproject's repository, the presumption is the superproject and
+submodule repositories will be kept together in the same relative
+location, and only the superproject's URL needs to be provided.
+git-submodule will correctly locate the submodule using the relative
+URL in `.gitmodules`.
status [--cached] [--recursive] [--] [<path>...]::
Show the status of the submodules. This will print the SHA-1 of the
currently checked out commit for each submodule, along with the
submodule path and the output of 'git describe' for the
- SHA-1. Each SHA-1 will be prefixed with `-` if the submodule is not
- initialized, `+` if the currently checked out submodule commit
+ SHA-1. Each SHA-1 will possibly be prefixed with `-` if the submodule is
+ not initialized, `+` if the currently checked out submodule commit
does not match the SHA-1 found in the index of the containing
repository and `U` if the submodule has merge conflicts.
+
@@ -123,13 +86,15 @@ too (and can also report changes to a submodule's work tree).
init [--] [<path>...]::
Initialize the submodules recorded in the index (which were
added and committed elsewhere) by setting `submodule.$name.url`
- in .git/config. It uses the same setting from .gitmodules as
+ in .git/config. It uses the same setting from `.gitmodules` as
a template. If the URL is relative, it will be resolved using
the default remote. If there is no default remote, the current
repository will be assumed to be upstream.
+
Optional <path> arguments limit which submodules will be initialized.
-If no path is specified, all submodules are initialized.
+If no path is specified and submodule.active has been configured, submodules
+configured to be active will be initialized, otherwise all submodules are
+initialized.
+
When present, it will also copy the value of `submodule.$name.update`.
This command does not alter existing information in .git/config.
@@ -139,7 +104,7 @@ you can also just use `git submodule update --init` without
the explicit 'init' step if you do not intend to customize
any submodule locations.
+
-See the add subcommand for the defintion of default remote.
+See the add subcommand for the definition of default remote.
deinit [-f|--force] (--all|[--] <path>...)::
Unregister the given submodules, i.e. remove the whole
@@ -147,15 +112,17 @@ deinit [-f|--force] (--all|[--] <path>...)::
tree. Further calls to `git submodule update`, `git submodule foreach`
and `git submodule sync` will skip any unregistered submodules until
they are initialized again, so use this command if you don't want to
- have a local checkout of the submodule in your working tree anymore. If
- you really want to remove a submodule from the repository and commit
- that use linkgit:git-rm[1] instead.
+ have a local checkout of the submodule in your working tree anymore.
+
When the command is run without pathspec, it errors out,
instead of deinit-ing everything, to prevent mistakes.
+
If `--force` is specified, the submodule's working tree will
be removed even if it contains local modifications.
++
+If you really want to remove a submodule from the repository and commit
+that use linkgit:git-rm[1] instead. See linkgit:gitsubmodules[7] for removal
+options.
update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--depth <depth>] [--recursive] [--jobs <n>] [--] [<path>...]::
+
@@ -165,15 +132,15 @@ expects by cloning missing submodules and updating the working tree of
the submodules. The "updating" can be done in several ways depending
on command line options and the value of `submodule.<name>.update`
configuration variable. The command line option takes precedence over
-the configuration variable. if neither is given, a checkout is performed.
-update procedures supported both from the command line as well as setting
-`submodule.<name>.update`:
+the configuration variable. If neither is given, a 'checkout' is performed.
+The 'update' procedures supported both from the command line as well as
+through the `submodule.<name>.update` configuration are:
checkout;; the commit recorded in the superproject will be
checked out in the submodule on a detached HEAD.
+
If `--force` is specified, the submodule will be checked out (using
-`git checkout --force` if appropriate), even if the commit specified
+`git checkout --force`), even if the commit specified
in the index of the containing repository already matches the commit
checked out in the submodule.
@@ -183,8 +150,8 @@ checked out in the submodule.
merge;; the commit recorded in the superproject will be merged
into the current branch in the submodule.
-The following procedures are only available via the `submodule.<name>.update`
-configuration variable:
+The following 'update' procedures are only available via the
+`submodule.<name>.update` configuration variable:
custom command;; arbitrary shell command that takes a single
argument (the sha1 of the commit recorded in the
@@ -195,7 +162,7 @@ configuration variable:
none;; the submodule is not updated.
If the submodule is not yet initialized, and you just want to use the
-setting as stored in .gitmodules, you can automatically initialize the
+setting as stored in `.gitmodules`, you can automatically initialize the
submodule with the `--init` option.
If `--recursive` is specified, this command will recurse into the
@@ -216,12 +183,17 @@ information too.
foreach [--recursive] <command>::
Evaluates an arbitrary shell command in each checked out submodule.
- The command has access to the variables $name, $path, $sha1 and
- $toplevel:
- $name is the name of the relevant submodule section in .gitmodules,
- $path is the name of the submodule directory relative to the
- superproject, $sha1 is the commit as recorded in the superproject,
- and $toplevel is the absolute path to the top-level of the superproject.
+ The command has access to the variables $name, $sm_path, $displaypath,
+ $sha1 and $toplevel:
+ $name is the name of the relevant submodule section in `.gitmodules`,
+ $sm_path is the path of the submodule as recorded in the immediate
+ superproject, $displaypath contains the relative path from the
+ current working directory to the submodules root directory,
+ $sha1 is the commit as recorded in the immediate
+ superproject, and $toplevel is the absolute path to the top-level
+ of the immediate superproject.
+ Note that to avoid conflicts with '$PATH' on Windows, the '$path'
+ variable is now a deprecated synonym of '$sm_path' variable.
Any submodules defined in the superproject but not checked out are
ignored by this command. Unless given `--quiet`, foreach prints the name
of each submodule before evaluating the command.
@@ -240,14 +212,14 @@ git submodule foreach 'echo $path `git rev-parse HEAD`'
sync [--recursive] [--] [<path>...]::
Synchronizes submodules' remote URL configuration setting
- to the value specified in .gitmodules. It will only affect those
+ to the value specified in `.gitmodules`. It will only affect those
submodules which already have a URL entry in .git/config (that is the
case when they are initialized or freshly added). This is useful when
submodule URLs change upstream and you need to update your local
repositories accordingly.
+
-"git submodule sync" synchronizes all submodules while
-"git submodule sync \-- A" synchronizes submodule "A" only.
+`git submodule sync` synchronizes all submodules while
+`git submodule sync -- A` synchronizes submodule "A" only.
+
If `--recursive` is specified, this command will recurse into the
registered submodules, and sync any nested submodules within.
@@ -272,6 +244,13 @@ OPTIONS
--quiet::
Only print error messages.
+--progress::
+ This option is only valid for add and update commands.
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if the
+ standard error stream is not directed to a terminal.
+
--all::
This option is only valid for the deinit command. Unregister all
submodules in the working tree.
@@ -395,7 +374,15 @@ the submodule itself.
this option will be passed to the linkgit:git-clone[1] command.
+
*NOTE*: Do *not* use this option unless you have read the note
-for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully.
+for linkgit:git-clone[1]'s `--reference`, `--shared`, and `--dissociate`
+options carefully.
+
+--dissociate::
+ This option is only valid for add and update commands. These
+ commands sometimes need to clone a remote repository. In this case,
+ this option will be passed to the linkgit:git-clone[1] command.
++
+*NOTE*: see the NOTE for the `--reference` option.
--recursive::
This option is only valid for foreach, update, status and sync commands.
@@ -411,7 +398,7 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully.
--[no-]recommend-shallow::
This option is only valid for the update command.
The initial clone of a submodule will use the recommended
- `submodule.<name>.shallow` as provided by the .gitmodules file
+ `submodule.<name>.shallow` as provided by the `.gitmodules` file
by default. To ignore the suggestions use `--no-recommend-shallow`.
-j <n>::
@@ -427,12 +414,16 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully.
FILES
-----
-When initializing submodules, a .gitmodules file in the top-level directory
+When initializing submodules, a `.gitmodules` file in the top-level directory
of the containing repository is used to find the url of each submodule.
This file should be formatted in the same way as `$GIT_DIR/config`. The key
to each submodule url is "submodule.$name.url". See linkgit:gitmodules[5]
for details.
+SEE ALSO
+--------
+linkgit:gitsubmodules[7], linkgit:gitmodules[5].
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/en/git-svn.txt b/en/git-svn.txt
index 9bee9b0c4c53692bab569577d584797c0bd9e217..b99029520d9b17e76ab65b4333a79fe20ed22eff 100644
--- a/en/git-svn.txt
+++ b/en/git-svn.txt
@@ -8,7 +8,7 @@ git-svn - Bidirectional operation between a Subversion repository and Git
SYNOPSIS
--------
[verse]
-'git svn' <command> [options] [arguments]
+'git svn' <command> [<options>] [<arguments>]
DESCRIPTION
-----------
@@ -95,6 +95,10 @@ If you still want the old default, you can get it by passing
`--prefix ""` on the command line (`--prefix=""` may not work if
your Perl's Getopt::Long is < v2.37).
+--ignore-refs=<regex>;;
+ When passed to 'init' or 'clone' this regular expression will
+ be preserved as a config key. See 'fetch' for a description
+ of `--ignore-refs`.
--ignore-paths=<regex>;;
When passed to 'init' or 'clone' this regular expression will
be preserved as a config key. See 'fetch' for a description
@@ -138,6 +142,18 @@ the same local time zone.
--parent;;
Fetch only from the SVN parent of the current HEAD.
+--ignore-refs=<regex>;;
+ Ignore refs for branches or tags matching the Perl regular
+ expression. A "negative look-ahead assertion" like
+ `^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$`
+ can be used to allow only certain refs.
++
+[verse]
+config key: svn-remote.<name>.ignore-refs
++
+If the ignore-refs configuration key is set, and the command-line
+option is also given, both regular expressions will be used.
+
--ignore-paths=<regex>;;
This allows one to specify a Perl regular expression that will
cause skipping of all matching paths from checkout from SVN.
@@ -408,7 +424,7 @@ Any other arguments are passed directly to 'git log'
'set-tree'::
You should consider using 'dcommit' instead of this command.
Commit specified commit or tree objects to SVN. This relies on
- your imported fetch data being up-to-date. This makes
+ your imported fetch data being up to date. This makes
absolutely no attempts to do patching when committing to SVN, it
simply overwrites files with those specified in the tree or
commit. All merging is assumed to have taken place
@@ -436,13 +452,28 @@ Any other arguments are passed directly to 'git log'
'commit-diff'::
Commits the diff of two tree-ish arguments from the
- command-line. This command does not rely on being inside an `git svn
+ command-line. This command does not rely on being inside a `git svn
init`-ed repository. This command takes three arguments, (a) the
original tree to diff against, (b) the new tree result, (c) the
URL of the target Subversion repository. The final argument
(URL) may be omitted if you are working from a 'git svn'-aware
repository (that has been `init`-ed with 'git svn').
The -r<revision> option is required for this.
++
+The commit message is supplied either directly with the `-m` or `-F`
+option, or indirectly from the tag or commit when the second tree-ish
+denotes such an object, or it is requested by invoking an editor (see
+`--edit` option below).
+
+-m <msg>;;
+--message=<msg>;;
+ Use the given `msg` as the commit message. This option
+ disables the `--edit` option.
+
+-F <filename>;;
+--file=<filename>;;
+ Take the commit message from the given file. This option
+ disables the `--edit` option.
'info'::
Shows information about a file or directory similar to what
@@ -604,7 +635,8 @@ config key: svn.findcopiesharder
-A<filename>::
--authors-file=<filename>::
- Syntax is compatible with the file used by 'git cvsimport':
+ Syntax is compatible with the file used by 'git cvsimport' but
+ an empty email address can be supplied with '<>':
+
------------------------------------------------------------------------
loginname = Joe User <user@example.com>
@@ -623,8 +655,14 @@ config key: svn.authorsfile
If this option is specified, for each SVN committer name that
does not exist in the authors file, the given file is executed
with the committer name as the first argument. The program is
- expected to return a single line of the form "Name <email>",
- which will be treated as if included in the authors file.
+ expected to return a single line of the form "Name <email>" or
+ "Name <>", which will be treated as if included in the authors
+ file.
++
+Due to historical reasons a relative 'filename' is first searched
+relative to the current directory for 'init' and 'clone' and relative
+to the root of the working tree for 'fetch'. If 'filename' is
+not found, it is searched like any other command in '$PATH'.
+
[verse]
config key: svn.authorsProg
@@ -669,7 +707,7 @@ creating the branch or tag.
config key: svn.useLogAuthor
--add-author-from::
- When committing to svn from Git (as part of 'commit-diff', 'set-tree' or 'dcommit'
+ When committing to svn from Git (as part of 'set-tree' or 'dcommit'
operations), if the existing log message doesn't already have a
`From:` or `Signed-off-by:` line, append a `From:` line based on the
Git commit's author string. If you use this, then `--use-log-author`
diff --git a/en/git-tag.txt b/en/git-tag.txt
index 525737a5d891bb4a8b4df92c26a20550a927a0b9..a74e7b926d030f6f385e49be68714133f6e3c06e 100644
--- a/en/git-tag.txt
+++ b/en/git-tag.txt
@@ -9,12 +9,13 @@ git-tag - Create, list, delete or verify a tag object signed with GPG
SYNOPSIS
--------
[verse]
-'git tag' [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>]
+'git tag' [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>] [-e]
<tagname> [<commit> | <object>]
'git tag' -d <tagname>...
-'git tag' [-n[<num>]] -l [--contains <commit>] [--points-at <object>]
- [--column[=<options>] | --no-column] [--create-reflog] [--sort=<key>]
- [--format=<format>] [--[no-]merged [<commit>]] [<pattern>...]
+'git tag' [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
+ [--points-at <object>] [--column[=<options>] | --no-column]
+ [--create-reflog] [--sort=<key>] [--format=<format>]
+ [--[no-]merged [<commit>]] [<pattern>...]
'git tag' -v [--format=<format>] <tagname>...
DESCRIPTION
@@ -33,8 +34,8 @@ in the tag message.
If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <keyid>`
are absent, `-a` is implied.
-Otherwise just a tag reference for the SHA-1 object name of the commit object is
-created (i.e. a lightweight tag).
+Otherwise, a tag reference that points directly at the given object
+(i.e., a lightweight tag) is created.
A GnuPG signed tag object will be created when `-s` or `-u
<keyid>` is used. When `-u <keyid>` is not used, the
@@ -82,18 +83,24 @@ OPTIONS
-n<num>::
<num> specifies how many lines from the annotation, if any,
- are printed when using -l.
- 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 <pattern>::
---list <pattern>::
- List tags with names that match the given pattern (or all if no
- pattern is given). 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.
+ 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::
+ 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
+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 based on the key given. Prefix `-` to sort in
@@ -108,6 +115,11 @@ OPTIONS
variable if it exists, or lexicographic order otherwise. See
linkgit:git-config[1].
+--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).
+
-i::
--ignore-case::
Sorting and filtering tags are case insensitive.
@@ -122,10 +134,23 @@ This option is only applicable when listing tags without annotation lines.
--contains [<commit>]::
Only list tags which contain the specified commit (HEAD if not
- specified).
+ specified). Implies `--list`.
+
+--no-contains [<commit>]::
+ Only list tags which don't contain the specified commit (HEAD if
+ not specified). Implies `--list`.
+
+--merged [<commit>]::
+ Only list tags whose commits are reachable from the specified
+ commit (`HEAD` if not specified), incompatible with `--no-merged`.
+
+--no-merged [<commit>]::
+ Only list tags whose commits are not reachable from the specified
+ commit (`HEAD` if not specified), incompatible with `--merged`.
--points-at <object>::
- Only list tags of the given object.
+ Only list tags of the given object (HEAD if not
+ specified). Implies `--list`.
-m <msg>::
--message=<msg>::
@@ -142,6 +167,12 @@ This option is only applicable when listing tags without annotation lines.
Implies `-a` if none of `-a`, `-s`, or `-u <keyid>`
is given.
+-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.
+
--cleanup=<mode>::
This option sets how the tag message is cleaned up.
The '<mode>' can be one of 'verbatim', 'whitespace' and 'strip'. The
@@ -154,7 +185,13 @@ This option is only applicable when listing tags without annotation lines.
`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`.
+ `core.logAllRefUpdates`.
+
+--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>::
The name of the tag to create, delete, or describe.
@@ -167,17 +204,6 @@ This option is only applicable when listing tags without annotation lines.
The object that the new tag will refer to, usually a commit.
Defaults to HEAD.
-<format>::
- A string that interpolates `%(fieldname)` from the object
- pointed at by a ref being shown. The format is the same as
- that of linkgit:git-for-each-ref[1]. When unspecified,
- defaults to `%(refname:strip=2)`.
-
---[no-]merged [<commit>]::
- Only list tags whose tips are reachable, or not reachable
- if `--no-merged` is used, from the specified commit (`HEAD`
- if not specified).
-
CONFIGURATION
-------------
By default, 'git tag' in sign-with-default mode (-s) will use your
@@ -190,6 +216,9 @@ it in the repository configuration as follows:
signingKey = <gpg-keyid>
-------------------------------------
+`pager.tag` is only respected when listing tags, i.e., when `-l` is
+used or implied. The default is to use a pager.
+See linkgit:git-config[1].
DISCUSSION
----------
@@ -208,16 +237,16 @@ your repository directly), then others will have already seen
the old tag. In that case you can do one of two things:
. The sane thing.
-Just admit you screwed up, and use a different name. Others have
-already seen one tag-name, and if you keep the same name, you
-may be in the situation that two people both have "version X",
-but they actually have 'different' "X"'s. So just call it "X.1"
-and be done with it.
+ Just admit you screwed up, and use a different name. Others have
+ already seen one tag-name, and if you keep the same name, you
+ may be in the situation that two people both have "version X",
+ but they actually have 'different' "X"'s. So just call it "X.1"
+ and be done with it.
. 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'
-again, as if you hadn't already published the old one.
+ 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'
+ 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
diff --git a/en/git-update-index.txt b/en/git-update-index.txt
index 1579abf3c3b45f4e63f8f17746dde31a06a3a564..1c4d146a41ce091755b2e4baef0fa79f45a4b515 100644
--- a/en/git-update-index.txt
+++ b/en/git-update-index.txt
@@ -16,9 +16,11 @@ SYNOPSIS
[--chmod=(+|-)x]
[--[no-]assume-unchanged]
[--[no-]skip-worktree]
+ [--[no-]fsmonitor-valid]
[--ignore-submodules]
[--[no-]split-index]
[--[no-|test-|force-]untracked-cache]
+ [--[no-]fsmonitor]
[--really-refresh] [--unresolve] [--again | -g]
[--info-only] [--index-info]
[-z] [--stdin] [--index-version <n>]
@@ -111,6 +113,12 @@ you will need to handle the situation manually.
set and unset the "skip-worktree" bit for the paths. See
section "Skip-worktree bit" below for more information.
+--[no-]fsmonitor-valid::
+ When one of these flags is specified, the object name recorded
+ for the paths are not updated. Instead, these options
+ set and unset the "fsmonitor valid" bit for the paths. See
+ section "File System Monitor" below for more information.
+
-g::
--again::
Runs 'git update-index' itself on the paths whose index
@@ -153,7 +161,7 @@ you will need to handle the situation manually.
+
Version 4 performs a simple pathname compression that reduces index
size by 30%-50% on large repositories, which results in faster load
-time. Version 4 is relatively young (first released in in 1.8.0 in
+time. Version 4 is relatively young (first released in 1.8.0 in
October 2012). Other Git implementations such as JGit and libgit2
may not support it yet.
@@ -201,6 +209,15 @@ will remove the intended effect of the option.
`--untracked-cache` used to imply `--test-untracked-cache` but
this option would enable the extension unconditionally.
+--fsmonitor::
+--no-fsmonitor::
+ Enable or disable files system monitor feature. These options
+ take effect whatever the value of the `core.fsmonitor`
+ configuration variable (see linkgit:git-config[1]). But a warning
+ is emitted when the change goes against the configured value, as
+ the configured value will take effect next time the index is
+ read and this will remove the intended effect of the option.
+
\--::
Do not interpret any more arguments as options.
@@ -211,10 +228,10 @@ will remove the intended effect of the option.
cleaner names.
The same applies to directories ending '/' and paths with '//'
-Using --refresh
+USING --REFRESH
---------------
`--refresh` does not calculate a new sha1 file or bring the index
-up-to-date for mode/content changes. But what it *does* do is to
+up to date for mode/content changes. But what it *does* do is to
"re-match" the stat information of a file with the index, so that you
can refresh the index for a file that hasn't been changed but where
the stat entry is out of date.
@@ -222,16 +239,16 @@ the stat entry is out of date.
For example, you'd want to do this after doing a 'git read-tree', to link
up the stat index details with the proper files.
-Using --cacheinfo or --info-only
+USING --CACHEINFO OR --INFO-ONLY
--------------------------------
`--cacheinfo` is used to register a file that is not in the
current working directory. This is useful for minimum-checkout
merging.
-To pretend you have a file with mode and sha1 at path, say:
+To pretend you have a file at path with mode and sha1, say:
----------------
-$ git update-index --cacheinfo <mode>,<sha1>,<path>
+$ git update-index --add --cacheinfo <mode>,<sha1>,<path>
----------------
`--info-only` is used to register files without placing them in the object
@@ -244,30 +261,27 @@ useful when the file is available, but you do not wish to update the
object database.
-Using --index-info
+USING --INDEX-INFO
------------------
`--index-info` is a more powerful mechanism that lets you feed
multiple entry definitions from the standard input, and designed
specifically for scripts. It can take inputs of three formats:
- . mode SP sha1 TAB path
-+
-The first format is what "git-apply --index-info"
-reports, and used to reconstruct a partial tree
-that is used for phony merge base tree when falling
-back on 3-way merge.
-
. mode SP type SP sha1 TAB path
+
-The second format is to stuff 'git ls-tree' output
-into the index file.
+This format is to stuff `git ls-tree` output into the index.
. mode SP sha1 SP stage TAB path
+
This format is to put higher order stages into the
index file and matches 'git ls-files --stage' output.
+ . mode SP sha1 TAB path
++
+This format is no longer produced by any Git command, but is
+and will continue to be supported by `update-index --index-info`.
+
To place a higher stage entry to the index, the path should
first be removed by feeding a mode=0 entry for the path, and
then feeding necessary input lines in the third format.
@@ -300,7 +314,7 @@ $ git ls-files -s
------------
-Using ``assume unchanged'' bit
+USING ``ASSUME UNCHANGED'' BIT
------------------------------
Many operations in Git depend on your filesystem to have an
@@ -333,7 +347,7 @@ the index (use `git update-index --really-refresh` if you want
to mark them as "assume unchanged").
-Examples
+EXAMPLES
--------
To update and refresh only the files already checked out:
@@ -370,7 +384,7 @@ M foo.c
<9> now it checks with lstat(2) and finds it has been changed.
-Skip-worktree bit
+SKIP-WORKTREE BIT
-----------------
Skip-worktree bit can be defined in one (long) sentence: When reading
@@ -390,7 +404,7 @@ Although this bit looks similar to assume-unchanged bit, its goal is
different from assume-unchanged bit's. Skip-worktree also takes
precedence over assume-unchanged bit when both are set.
-Split index
+SPLIT INDEX
-----------
This mode is designed for repositories with very large indexes, and
@@ -415,7 +429,7 @@ To avoid deleting a shared index file that is still used, its
modification time is updated to the current time everytime a new split
index based on the shared index file is either created or read from.
-Untracked cache
+UNTRACKED CACHE
---------------
This cache is meant to speed up commands that involve determining
@@ -447,7 +461,61 @@ command reads the index; while when `--[no-|force-]untracked-cache`
are used, the untracked cache is immediately added to or removed from
the index.
-Configuration
+Before 2.17, the untracked cache had a bug where replacing a directory
+with a symlink to another directory could cause it to incorrectly show
+files tracked by git as untracked. See the "status: add a failing test
+showing a core.untrackedCache bug" commit to git.git. A workaround for
+that is (and this might work for other undiscovered bugs in the
+future):
+
+----------------
+$ git -c core.untrackedCache=false status
+----------------
+
+This bug has also been shown to affect non-symlink cases of replacing
+a directory with a file when it comes to the internal structures of
+the untracked cache, but no case has been reported where this resulted in
+wrong "git status" output.
+
+There are also cases where existing indexes written by git versions
+before 2.17 will reference directories that don't exist anymore,
+potentially causing many "could not open directory" warnings to be
+printed on "git status". These are new warnings for existing issues
+that were previously silently discarded.
+
+As with the bug described above the solution is to one-off do a "git
+status" run with `core.untrackedCache=false` to flush out the leftover
+bad data.
+
+FILE SYSTEM MONITOR
+-------------------
+
+This feature is intended to speed up git operations for repos that have
+large working directories.
+
+It enables git to work together with a file system monitor (see the
+"fsmonitor-watchman" section of linkgit:githooks[5]) that can
+inform it as to what files have been modified. This enables git to avoid
+having to lstat() every file to find modified files.
+
+When used in conjunction with the untracked cache, it can further improve
+performance by avoiding the cost of scanning the entire working directory
+looking for new files.
+
+If you want to enable (or disable) this feature, it is easier to use
+the `core.fsmonitor` configuration variable (see
+linkgit:git-config[1]) than using the `--fsmonitor` option to
+`git update-index` in each repository, especially if you want to do so
+across all repositories you use, because you can set the configuration
+variable in your `$HOME/.gitconfig` just once and have it affect all
+repositories you touch.
+
+When the `core.fsmonitor` configuration variable is changed, the
+file system monitor is added to or removed from the index the next time
+a command reads the index. When `--[no-]fsmonitor` are used, the file
+system monitor is immediately added to or removed from the index.
+
+CONFIGURATION
-------------
The command honors `core.filemode` configuration variable. If
diff --git a/en/git-update-ref.txt b/en/git-update-ref.txt
index 969bfab2ab422ca8b7bdf2eb3ba45edc92fcd00b..96714231179cac8242f1bd0f781503d607c4add3 100644
--- a/en/git-update-ref.txt
+++ b/en/git-update-ref.txt
@@ -8,7 +8,7 @@ git-update-ref - Update the object name stored in a ref safely
SYNOPSIS
--------
[verse]
-'git update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] [--create-reflog] <ref> <newvalue> [<oldvalue>] | --stdin [-z])
+'git update-ref' [-m <reason>] [--no-deref] (-d <ref> [<oldvalue>] | [--create-reflog] <ref> <newvalue> [<oldvalue>] | --stdin [-z])
DESCRIPTION
-----------
@@ -120,7 +120,7 @@ modifications are performed. Note that while each individual
<ref> is updated or deleted atomically, a concurrent reader may
still see a subset of the modifications.
-Logging Updates
+LOGGING UPDATES
---------------
If config parameter "core.logAllRefUpdates" is true and the ref is one under
"refs/heads/", "refs/remotes/", "refs/notes/", or the symbolic ref HEAD; or
@@ -129,8 +129,8 @@ a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
symbolic refs before creating the log name) describing the change
in ref value. Log lines are formatted as:
- . oldsha1 SP newsha1 SP committer LF
-+
+ oldsha1 SP newsha1 SP committer LF
+
Where "oldsha1" is the 40 character hexadecimal value previously
stored in <ref>, "newsha1" is the 40 character hexadecimal value of
<newvalue> and "committer" is the committer's name, email address
@@ -138,8 +138,8 @@ and date in the standard Git committer ident format.
Optionally with -m:
- . oldsha1 SP newsha1 SP committer TAB message LF
-+
+ oldsha1 SP newsha1 SP committer TAB message LF
+
Where all fields are as described above and "message" is the
value supplied to the -m option.
diff --git a/en/git-upload-pack.txt b/en/git-upload-pack.txt
index 998f52d3df71e29d4178251de375d70cd570a1d8..9822c1eb1add168cdb30426bab04d925504d0205 100644
--- a/en/git-upload-pack.txt
+++ b/en/git-upload-pack.txt
@@ -22,7 +22,6 @@ The UI for the protocol is on the 'git fetch-pack' side, and the
program pair is meant to be used to pull updates from a remote
repository. For push operations, see 'git send-pack'.
-
OPTIONS
-------
diff --git a/en/git-var.txt b/en/git-var.txt
index 44ff9541df1f5dd432d37b5828bfb800f66dfae8..6072f936ab5e3a8b3aeafcaeddd81b7b6d5e0b01 100644
--- a/en/git-var.txt
+++ b/en/git-var.txt
@@ -23,14 +23,14 @@ OPTIONS
as well. (However, the configuration variables listing functionality
is deprecated in favor of `git config -l`.)
-EXAMPLE
+EXAMPLES
--------
$ git var GIT_AUTHOR_IDENT
Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
VARIABLES
-----------
+---------
GIT_AUTHOR_IDENT::
The author of a piece of code.
diff --git a/en/git-web--browse.txt b/en/git-web--browse.txt
index 2d6b09a43cd63e3ad768f9b49ba67f1deda05111..fd952a5ff92b72e67eac219fdfbbe5d7c708be81 100644
--- a/en/git-web--browse.txt
+++ b/en/git-web--browse.txt
@@ -8,7 +8,7 @@ git-web--browse - Git helper script to launch a web browser
SYNOPSIS
--------
[verse]
-'git web{litdd}browse' [OPTIONS] URL/FILE ...
+'git web{litdd}browse' [<options>] <url|file>...
DESCRIPTION
-----------
@@ -84,7 +84,7 @@ variable exists then 'git web{litdd}browse' will treat the specified tool
as a custom command and will use a shell eval to run the command with
the URLs passed as arguments.
-Note about konqueror
+NOTE ABOUT KONQUEROR
--------------------
When 'konqueror' is specified by a command-line option or a
diff --git a/en/git-worktree.txt b/en/git-worktree.txt
index 553cf8413f1792b2eec4c8827996e32f143b817a..cb86318f3e1b34e0eda5b9886fc934456434e7a8 100644
--- a/en/git-worktree.txt
+++ b/en/git-worktree.txt
@@ -9,10 +9,12 @@ git-worktree - Manage multiple working trees
SYNOPSIS
--------
[verse]
-'git worktree add' [-f] [--detach] [--checkout] [-b <new-branch>] <path> [<branch>]
+'git worktree add' [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>]
'git worktree list' [--porcelain]
'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 unlock' <worktree>
DESCRIPTION
@@ -25,19 +27,16 @@ out more than one branch at a time. With `git worktree add` a new working
tree is associated with the repository. This new working tree is called a
"linked working tree" as opposed to the "main working tree" prepared by "git
init" or "git clone". A repository has one main working tree (if it's not a
-bare repository) and zero or more linked working trees.
+bare repository) and zero or more linked working trees. When you are done
+with a linked working tree, remove it with `git worktree remove`.
-When you are done with a linked working tree you can simply delete it.
-The working tree's administrative files in the repository (see
-"DETAILS" below) will eventually be removed automatically (see
+If a working tree is deleted without using `git worktree remove`, then
+its associated administrative files, which reside in the repository
+(see "DETAILS" below), will eventually be removed automatically (see
`gc.worktreePruneExpire` in linkgit:git-config[1]), or you can run
`git worktree prune` in the main or any linked working tree to
clean up any stale administrative files.
-If you move a linked working tree, you need to manually update the
-administrative files so that they do not get pruned automatically. See
-section "DETAILS" for more information.
-
If a linked working tree is stored on a portable device or network share
which is not always mounted, you can prevent its administrative files from
being pruned by issuing the `git worktree lock` command, optionally
@@ -45,16 +44,39 @@ specifying `--reason` to explain why the working tree is locked.
COMMANDS
--------
-add <path> [<branch>]::
+add <path> [<commit-ish>]::
-Create `<path>` and checkout `<branch>` into it. The new working directory
+Create `<path>` and checkout `<commit-ish>` into it. The new working directory
is linked to the current repository, sharing everything except working
directory specific files such as HEAD, index, etc. `-` may also be
-specified as `<branch>`; it is synonymous with `@{-1}`.
+specified as `<commit-ish>`; it is synonymous with `@{-1}`.
++
+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>`)
+with a matching name, treat as equivalent to:
++
+------------
+$ git worktree add --track -b <branch> <path> <remote>/<branch>
+------------
++
+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
+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
+'origin' remote. See also `checkout.defaultRemote` in
+linkgit:git-config[1].
+
-If `<branch>` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a new branch based at HEAD is created automatically,
-as if `-b $(basename <path>)` was specified.
+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 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 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).
list::
@@ -71,10 +93,22 @@ 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 a working tree to a new location. Note that the main working tree
+or linked working trees containing submodules cannot be moved.
+
prune::
Prune working tree information in $GIT_DIR/worktrees.
+remove::
+
+Remove a working tree. Only clean working trees (no untracked files
+and no modification in tracked files) can be removed. Unclean working
+trees or ones with submodules can be removed with `--force`. The main
+working tree cannot be removed.
+
unlock::
Unlock a working tree, allowing it to be pruned, moved or deleted.
@@ -84,29 +118,59 @@ OPTIONS
-f::
--force::
- By default, `add` refuses to create a new working tree when `<branch>`
- is already checked out by another working tree. This option overrides
- that safeguard.
+ By default, `add` refuses to create a new working tree when
+ `<commit-ish>` is a branch name and is already checked out by
+ another working tree, or if `<path>` is already assigned to some
+ working tree but is missing (for instance, if `<path>` was deleted
+ manually). This option overrides these safeguards. To add a missing but
+ locked working tree path, specify `--force` twice.
++
+`move` refuses to move a locked working tree unless `--force` is specified
+twice.
++
+`remove` refuses to remove an unclean working tree unless `--force` is used.
+To remove a locked working tree, specify `--force` twice.
-b <new-branch>::
-B <new-branch>::
With `add`, create a new branch named `<new-branch>` starting at
- `<branch>`, and check out `<new-branch>` into the new working tree.
- If `<branch>` is omitted, it defaults to HEAD.
+ `<commit-ish>`, and check out `<new-branch>` into the new working tree.
+ 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
- `<branch>`.
+ `<commit-ish>`.
--detach::
With `add`, detach HEAD in the new working tree. See "DETACHED HEAD"
in linkgit:git-checkout[1].
--[no-]checkout::
- By default, `add` checks out `<branch>`, however, `--no-checkout` can
+ 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-]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 working tree locked after creation. This is the
+ equivalent of `git worktree lock` after `git worktree add`,
+ but without race condition.
+
-n::
--dry-run::
With `prune`, do not remove anything; just report what it would
@@ -117,6 +181,10 @@ OPTIONS
This format will remain stable across Git versions and regardless of user
configuration. See below for details.
+-q::
+--quiet::
+ With 'add', suppress feedback messages.
+
-v::
--verbose::
With `prune`, report all removals.
@@ -136,6 +204,65 @@ working trees, it can be used to identify worktrees. For example if
you only have two working trees, at "/abc/def/ghi" and "/abc/def/ggg",
then "ghi" or "def/ghi" is enough to point to the former working tree.
+REFS
+----
+In multiple working trees, some refs may be shared between all working
+trees, some refs are local. One example is HEAD is different for all
+working trees. This section is about the sharing rules and how to access
+refs of one working tree from another.
+
+In general, all pseudo refs are per working tree 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 one
+exception to this: refs inside refs/bisect and refs/worktree is not
+shared.
+
+Refs that are per working tree can still be accessed from another
+working tree via two special paths, main-worktree and worktrees. The
+former gives access to per-worktree refs of the main working tree,
+while the latter to all linked working trees.
+
+For example, main-worktree/HEAD or main-worktree/refs/bisect/good
+resolve to the same value as the main working tree'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 working
+trees. If the config variables `core.bare` or `core.worktree` are
+already present in the config file, they will be applied to the main
+working trees only.
+
+In order to have configuration specific to working trees, you can turn
+on "worktreeConfig" extension, e.g.:
+
+------------
+$ git config extensions.worktreeConfig true
+------------
+
+In this mode, specific configuration stays in the path pointed by `git
+rev-parse --git-path config.worktree`. You can add or update
+configuration in this file with `git config --worktree`. Older Git
+versions will refuse to access repositories with this extension.
+
+Note that in this file, the exception for `core.bare` and `core.worktree`
+is gone. If you have them in $GIT_DIR/config before, you must move
+them to the `config.worktree` of the main working tree. You may also
+take this opportunity to review and move other configuration that you
+do not want to share to all working trees:
+
+ - `core.worktree` and `core.bare` should never be shared
+
+ - `core.sparseCheckout` is recommended per working tree, unless you
+ are sure you always use sparse checkout for all working trees.
+
DETAILS
-------
Each linked working tree has a private sub-directory in the repository's
@@ -160,14 +287,15 @@ linked working tree `git rev-parse --git-path HEAD` returns
`/path/other/test-next/.git/HEAD` or `/path/main/.git/HEAD`) while `git
rev-parse --git-path refs/heads/master` uses
$GIT_COMMON_DIR and returns `/path/main/.git/refs/heads/master`,
-since refs are shared across all working trees.
+since refs are shared across all working trees, except refs/bisect and
+refs/worktree.
See linkgit:gitrepository-layout[5] for more information. The rule of
thumb is do not make any assumption about whether a path belongs to
$GIT_DIR or $GIT_COMMON_DIR when you need to directly access something
inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path.
-If you move a linked working tree, you need to update the 'gitdir' file
+If you manually move a linked working tree, you need to update the 'gitdir' file
in the entry's directory. For example, if a linked working tree is moved
to `/newpath/test-next` and its `.git` file points to
`/path/main/.git/worktrees/test-next`, then update
@@ -185,13 +313,16 @@ to `/path/main/.git/worktrees/test-next` then a file named
`test-next` entry from being pruned. See
linkgit:gitrepository-layout[5] for details.
+When extensions.worktreeConfig is enabled, the config file
+`.git/worktrees/<id>/config.worktree` is read after `.git/config` is.
+
LIST OUTPUT FORMAT
------------------
The worktree list command has two output formats. The default format shows the
details on a single line with columns. For example:
------------
-S git worktree list
+$ git worktree list
/path/to/bare-source (bare)
/path/to/linked-worktree abcd1234 [master]
/path/to/other-linked-worktree 1234abc (detached HEAD)
@@ -202,11 +333,11 @@ Porcelain Format
The porcelain format has a line per attribute. Attributes are listed with a
label and value separated by a single space. Boolean attributes (like 'bare'
and 'detached') are listed as a label only, and are only present if and only
-if the value is true. An empty line indicates the end of a worktree. For
-example:
+if the value is true. The first attribute of a worktree is always `worktree`,
+an empty line indicates the end of the record. For example:
------------
-S git worktree list --porcelain
+$ git worktree list --porcelain
worktree /path/to/bare-source
bare
@@ -237,8 +368,7 @@ $ pushd ../temp
# ... hack hack hack ...
$ git commit -a -m 'emergency fix for boss'
$ popd
-$ rm -rf ../temp
-$ git worktree prune
+$ git worktree remove ../temp
------------
BUGS
@@ -247,13 +377,6 @@ Multiple checkout in general is still experimental, and the support
for submodules is incomplete. It is NOT recommended to make multiple
checkouts of a superproject.
-git-worktree could provide more automation for tasks currently
-performed manually, such as:
-
-- `remove` to remove a linked working tree and its administrative files (and
- warn if the working tree is dirty)
-- `mv` to move or rename a working tree and update its administrative files
-
GIT
---
Part of the linkgit:git[1] suite
diff --git a/en/git.txt b/en/git.txt
index 3f75af872c040ade3bebdf8ae196e158f0688141..00156d64aad51cd758e554ada68a52a3e55dfc0c 100644
--- a/en/git.txt
+++ b/en/git.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git' [--version] [--help] [-C <path>] [-c <name>=<value>]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
- [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+ [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
[--super-prefix=<path>]
<command> [<args>]
@@ -35,499 +35,6 @@ manual page gives you an overview of the command-line command syntax.
A formatted and hyperlinked copy of the latest Git documentation
can be viewed at `https://git.github.io/htmldocs/git.html`.
-ifdef::stalenotes[]
-[NOTE]
-============
-
-You are reading the documentation for the latest (possibly
-unreleased) version of Git, that is available from the 'master'
-branch of the `git.git` repository.
-Documentation for older releases are available here:
-
-* link:v2.12.1/git.html[documentation for release 2.12.1]
-
-* release notes for
- link:RelNotes/2.12.1.txt[2.12.1].
- link:RelNotes/2.12.0.txt[2.12].
-
-* link:v2.11.1/git.html[documentation for release 2.11.1]
-
-* release notes for
- link:RelNotes/2.11.1.txt[2.11.1],
- link:RelNotes/2.11.0.txt[2.11].
-
-* link:v2.10.2/git.html[documentation for release 2.10.2]
-
-* release notes for
- link:RelNotes/2.10.2.txt[2.10.2],
- link:RelNotes/2.10.1.txt[2.10.1],
- link:RelNotes/2.10.0.txt[2.10].
-
-* link:v2.9.3/git.html[documentation for release 2.9.3]
-
-* release notes for
- link:RelNotes/2.9.3.txt[2.9.3],
- link:RelNotes/2.9.2.txt[2.9.2],
- link:RelNotes/2.9.1.txt[2.9.1],
- link:RelNotes/2.9.0.txt[2.9].
-
-* link:v2.8.4/git.html[documentation for release 2.8.4]
-
-* release notes for
- link:RelNotes/2.8.4.txt[2.8.4],
- link:RelNotes/2.8.3.txt[2.8.3],
- link:RelNotes/2.8.2.txt[2.8.2],
- link:RelNotes/2.8.1.txt[2.8.1],
- link:RelNotes/2.8.0.txt[2.8].
-
-* link:v2.7.3/git.html[documentation for release 2.7.3]
-
-* release notes for
- link:RelNotes/2.7.3.txt[2.7.3],
- link:RelNotes/2.7.2.txt[2.7.2],
- link:RelNotes/2.7.1.txt[2.7.1],
- link:RelNotes/2.7.0.txt[2.7].
-
-* link:v2.6.6/git.html[documentation for release 2.6.6]
-
-* release notes for
- link:RelNotes/2.6.6.txt[2.6.6],
- link:RelNotes/2.6.5.txt[2.6.5],
- link:RelNotes/2.6.4.txt[2.6.4],
- link:RelNotes/2.6.3.txt[2.6.3],
- link:RelNotes/2.6.2.txt[2.6.2],
- link:RelNotes/2.6.1.txt[2.6.1],
- link:RelNotes/2.6.0.txt[2.6].
-
-* link:v2.5.5/git.html[documentation for release 2.5.5]
-
-* release notes for
- link:RelNotes/2.5.5.txt[2.5.5],
- link:RelNotes/2.5.4.txt[2.5.4],
- link:RelNotes/2.5.3.txt[2.5.3],
- link:RelNotes/2.5.2.txt[2.5.2],
- link:RelNotes/2.5.1.txt[2.5.1],
- link:RelNotes/2.5.0.txt[2.5].
-
-* link:v2.4.11/git.html[documentation for release 2.4.11]
-
-* release notes for
- link:RelNotes/2.4.11.txt[2.4.11],
- link:RelNotes/2.4.10.txt[2.4.10],
- link:RelNotes/2.4.9.txt[2.4.9],
- link:RelNotes/2.4.8.txt[2.4.8],
- link:RelNotes/2.4.7.txt[2.4.7],
- link:RelNotes/2.4.6.txt[2.4.6],
- link:RelNotes/2.4.5.txt[2.4.5],
- link:RelNotes/2.4.4.txt[2.4.4],
- link:RelNotes/2.4.3.txt[2.4.3],
- link:RelNotes/2.4.2.txt[2.4.2],
- link:RelNotes/2.4.1.txt[2.4.1],
- link:RelNotes/2.4.0.txt[2.4].
-
-* link:v2.3.10/git.html[documentation for release 2.3.10]
-
-* release notes for
- link:RelNotes/2.3.10.txt[2.3.10],
- link:RelNotes/2.3.9.txt[2.3.9],
- link:RelNotes/2.3.8.txt[2.3.8],
- link:RelNotes/2.3.7.txt[2.3.7],
- link:RelNotes/2.3.6.txt[2.3.6],
- link:RelNotes/2.3.5.txt[2.3.5],
- link:RelNotes/2.3.4.txt[2.3.4],
- link:RelNotes/2.3.3.txt[2.3.3],
- link:RelNotes/2.3.2.txt[2.3.2],
- link:RelNotes/2.3.1.txt[2.3.1],
- link:RelNotes/2.3.0.txt[2.3].
-
-* link:v2.2.3/git.html[documentation for release 2.2.3]
-
-* release notes for
- link:RelNotes/2.2.3.txt[2.2.3],
- link:RelNotes/2.2.2.txt[2.2.2],
- link:RelNotes/2.2.1.txt[2.2.1],
- link:RelNotes/2.2.0.txt[2.2].
-
-* link:v2.1.4/git.html[documentation for release 2.1.4]
-
-* release notes for
- link:RelNotes/2.1.4.txt[2.1.4],
- link:RelNotes/2.1.3.txt[2.1.3],
- link:RelNotes/2.1.2.txt[2.1.2],
- link:RelNotes/2.1.1.txt[2.1.1],
- link:RelNotes/2.1.0.txt[2.1].
-
-* link:v2.0.5/git.html[documentation for release 2.0.5]
-
-* release notes for
- link:RelNotes/2.0.5.txt[2.0.5],
- link:RelNotes/2.0.4.txt[2.0.4],
- link:RelNotes/2.0.3.txt[2.0.3],
- link:RelNotes/2.0.2.txt[2.0.2],
- link:RelNotes/2.0.1.txt[2.0.1],
- link:RelNotes/2.0.0.txt[2.0.0].
-
-* link:v1.9.5/git.html[documentation for release 1.9.5]
-
-* release notes for
- link:RelNotes/1.9.5.txt[1.9.5],
- link:RelNotes/1.9.4.txt[1.9.4],
- link:RelNotes/1.9.3.txt[1.9.3],
- link:RelNotes/1.9.2.txt[1.9.2],
- link:RelNotes/1.9.1.txt[1.9.1],
- link:RelNotes/1.9.0.txt[1.9.0].
-
-* link:v1.8.5.6/git.html[documentation for release 1.8.5.6]
-
-* release notes for
- link:RelNotes/1.8.5.6.txt[1.8.5.6],
- link:RelNotes/1.8.5.5.txt[1.8.5.5],
- link:RelNotes/1.8.5.4.txt[1.8.5.4],
- link:RelNotes/1.8.5.3.txt[1.8.5.3],
- link:RelNotes/1.8.5.2.txt[1.8.5.2],
- link:RelNotes/1.8.5.1.txt[1.8.5.1],
- link:RelNotes/1.8.5.txt[1.8.5].
-
-* link:v1.8.4.5/git.html[documentation for release 1.8.4.5]
-
-* release notes for
- link:RelNotes/1.8.4.5.txt[1.8.4.5],
- link:RelNotes/1.8.4.4.txt[1.8.4.4],
- link:RelNotes/1.8.4.3.txt[1.8.4.3],
- link:RelNotes/1.8.4.2.txt[1.8.4.2],
- link:RelNotes/1.8.4.1.txt[1.8.4.1],
- link:RelNotes/1.8.4.txt[1.8.4].
-
-* link:v1.8.3.4/git.html[documentation for release 1.8.3.4]
-
-* release notes for
- link:RelNotes/1.8.3.4.txt[1.8.3.4],
- link:RelNotes/1.8.3.3.txt[1.8.3.3],
- link:RelNotes/1.8.3.2.txt[1.8.3.2],
- link:RelNotes/1.8.3.1.txt[1.8.3.1],
- link:RelNotes/1.8.3.txt[1.8.3].
-
-* link:v1.8.2.3/git.html[documentation for release 1.8.2.3]
-
-* release notes for
- link:RelNotes/1.8.2.3.txt[1.8.2.3],
- link:RelNotes/1.8.2.2.txt[1.8.2.2],
- link:RelNotes/1.8.2.1.txt[1.8.2.1],
- link:RelNotes/1.8.2.txt[1.8.2].
-
-* link:v1.8.1.6/git.html[documentation for release 1.8.1.6]
-
-* release notes for
- link:RelNotes/1.8.1.6.txt[1.8.1.6],
- link:RelNotes/1.8.1.5.txt[1.8.1.5],
- link:RelNotes/1.8.1.4.txt[1.8.1.4],
- link:RelNotes/1.8.1.3.txt[1.8.1.3],
- link:RelNotes/1.8.1.2.txt[1.8.1.2],
- link:RelNotes/1.8.1.1.txt[1.8.1.1],
- link:RelNotes/1.8.1.txt[1.8.1].
-
-* link:v1.8.0.3/git.html[documentation for release 1.8.0.3]
-
-* release notes for
- link:RelNotes/1.8.0.3.txt[1.8.0.3],
- link:RelNotes/1.8.0.2.txt[1.8.0.2],
- link:RelNotes/1.8.0.1.txt[1.8.0.1],
- link:RelNotes/1.8.0.txt[1.8.0].
-
-* link:v1.7.12.4/git.html[documentation for release 1.7.12.4]
-
-* release notes for
- link:RelNotes/1.7.12.4.txt[1.7.12.4],
- link:RelNotes/1.7.12.3.txt[1.7.12.3],
- link:RelNotes/1.7.12.2.txt[1.7.12.2],
- link:RelNotes/1.7.12.1.txt[1.7.12.1],
- link:RelNotes/1.7.12.txt[1.7.12].
-
-* link:v1.7.11.7/git.html[documentation for release 1.7.11.7]
-
-* release notes for
- link:RelNotes/1.7.11.7.txt[1.7.11.7],
- link:RelNotes/1.7.11.6.txt[1.7.11.6],
- link:RelNotes/1.7.11.5.txt[1.7.11.5],
- link:RelNotes/1.7.11.4.txt[1.7.11.4],
- link:RelNotes/1.7.11.3.txt[1.7.11.3],
- link:RelNotes/1.7.11.2.txt[1.7.11.2],
- link:RelNotes/1.7.11.1.txt[1.7.11.1],
- link:RelNotes/1.7.11.txt[1.7.11].
-
-* link:v1.7.10.5/git.html[documentation for release 1.7.10.5]
-
-* release notes for
- link:RelNotes/1.7.10.5.txt[1.7.10.5],
- link:RelNotes/1.7.10.4.txt[1.7.10.4],
- link:RelNotes/1.7.10.3.txt[1.7.10.3],
- link:RelNotes/1.7.10.2.txt[1.7.10.2],
- link:RelNotes/1.7.10.1.txt[1.7.10.1],
- link:RelNotes/1.7.10.txt[1.7.10].
-
-* link:v1.7.9.7/git.html[documentation for release 1.7.9.7]
-
-* release notes for
- link:RelNotes/1.7.9.7.txt[1.7.9.7],
- link:RelNotes/1.7.9.6.txt[1.7.9.6],
- link:RelNotes/1.7.9.5.txt[1.7.9.5],
- link:RelNotes/1.7.9.4.txt[1.7.9.4],
- link:RelNotes/1.7.9.3.txt[1.7.9.3],
- link:RelNotes/1.7.9.2.txt[1.7.9.2],
- link:RelNotes/1.7.9.1.txt[1.7.9.1],
- link:RelNotes/1.7.9.txt[1.7.9].
-
-* link:v1.7.8.6/git.html[documentation for release 1.7.8.6]
-
-* release notes for
- link:RelNotes/1.7.8.6.txt[1.7.8.6],
- link:RelNotes/1.7.8.5.txt[1.7.8.5],
- link:RelNotes/1.7.8.4.txt[1.7.8.4],
- link:RelNotes/1.7.8.3.txt[1.7.8.3],
- link:RelNotes/1.7.8.2.txt[1.7.8.2],
- link:RelNotes/1.7.8.1.txt[1.7.8.1],
- link:RelNotes/1.7.8.txt[1.7.8].
-
-* link:v1.7.7.7/git.html[documentation for release 1.7.7.7]
-
-* release notes for
- link:RelNotes/1.7.7.7.txt[1.7.7.7],
- link:RelNotes/1.7.7.6.txt[1.7.7.6],
- link:RelNotes/1.7.7.5.txt[1.7.7.5],
- link:RelNotes/1.7.7.4.txt[1.7.7.4],
- link:RelNotes/1.7.7.3.txt[1.7.7.3],
- link:RelNotes/1.7.7.2.txt[1.7.7.2],
- link:RelNotes/1.7.7.1.txt[1.7.7.1],
- link:RelNotes/1.7.7.txt[1.7.7].
-
-* link:v1.7.6.6/git.html[documentation for release 1.7.6.6]
-
-* release notes for
- link:RelNotes/1.7.6.6.txt[1.7.6.6],
- link:RelNotes/1.7.6.5.txt[1.7.6.5],
- link:RelNotes/1.7.6.4.txt[1.7.6.4],
- link:RelNotes/1.7.6.3.txt[1.7.6.3],
- link:RelNotes/1.7.6.2.txt[1.7.6.2],
- link:RelNotes/1.7.6.1.txt[1.7.6.1],
- link:RelNotes/1.7.6.txt[1.7.6].
-
-* link:v1.7.5.4/git.html[documentation for release 1.7.5.4]
-
-* release notes for
- link:RelNotes/1.7.5.4.txt[1.7.5.4],
- link:RelNotes/1.7.5.3.txt[1.7.5.3],
- link:RelNotes/1.7.5.2.txt[1.7.5.2],
- link:RelNotes/1.7.5.1.txt[1.7.5.1],
- link:RelNotes/1.7.5.txt[1.7.5].
-
-* link:v1.7.4.5/git.html[documentation for release 1.7.4.5]
-
-* release notes for
- link:RelNotes/1.7.4.5.txt[1.7.4.5],
- link:RelNotes/1.7.4.4.txt[1.7.4.4],
- link:RelNotes/1.7.4.3.txt[1.7.4.3],
- link:RelNotes/1.7.4.2.txt[1.7.4.2],
- link:RelNotes/1.7.4.1.txt[1.7.4.1],
- link:RelNotes/1.7.4.txt[1.7.4].
-
-* link:v1.7.3.5/git.html[documentation for release 1.7.3.5]
-
-* release notes for
- link:RelNotes/1.7.3.5.txt[1.7.3.5],
- link:RelNotes/1.7.3.4.txt[1.7.3.4],
- link:RelNotes/1.7.3.3.txt[1.7.3.3],
- link:RelNotes/1.7.3.2.txt[1.7.3.2],
- link:RelNotes/1.7.3.1.txt[1.7.3.1],
- link:RelNotes/1.7.3.txt[1.7.3].
-
-* link:v1.7.2.5/git.html[documentation for release 1.7.2.5]
-
-* release notes for
- link:RelNotes/1.7.2.5.txt[1.7.2.5],
- link:RelNotes/1.7.2.4.txt[1.7.2.4],
- link:RelNotes/1.7.2.3.txt[1.7.2.3],
- link:RelNotes/1.7.2.2.txt[1.7.2.2],
- link:RelNotes/1.7.2.1.txt[1.7.2.1],
- link:RelNotes/1.7.2.txt[1.7.2].
-
-* link:v1.7.1.4/git.html[documentation for release 1.7.1.4]
-
-* release notes for
- link:RelNotes/1.7.1.4.txt[1.7.1.4],
- link:RelNotes/1.7.1.3.txt[1.7.1.3],
- link:RelNotes/1.7.1.2.txt[1.7.1.2],
- link:RelNotes/1.7.1.1.txt[1.7.1.1],
- link:RelNotes/1.7.1.txt[1.7.1].
-
-* link:v1.7.0.9/git.html[documentation for release 1.7.0.9]
-
-* release notes for
- link:RelNotes/1.7.0.9.txt[1.7.0.9],
- link:RelNotes/1.7.0.8.txt[1.7.0.8],
- link:RelNotes/1.7.0.7.txt[1.7.0.7],
- link:RelNotes/1.7.0.6.txt[1.7.0.6],
- link:RelNotes/1.7.0.5.txt[1.7.0.5],
- link:RelNotes/1.7.0.4.txt[1.7.0.4],
- link:RelNotes/1.7.0.3.txt[1.7.0.3],
- link:RelNotes/1.7.0.2.txt[1.7.0.2],
- link:RelNotes/1.7.0.1.txt[1.7.0.1],
- link:RelNotes/1.7.0.txt[1.7.0].
-
-* link:v1.6.6.3/git.html[documentation for release 1.6.6.3]
-
-* release notes for
- link:RelNotes/1.6.6.3.txt[1.6.6.3],
- link:RelNotes/1.6.6.2.txt[1.6.6.2],
- link:RelNotes/1.6.6.1.txt[1.6.6.1],
- link:RelNotes/1.6.6.txt[1.6.6].
-
-* link:v1.6.5.9/git.html[documentation for release 1.6.5.9]
-
-* release notes for
- link:RelNotes/1.6.5.9.txt[1.6.5.9],
- link:RelNotes/1.6.5.8.txt[1.6.5.8],
- link:RelNotes/1.6.5.7.txt[1.6.5.7],
- link:RelNotes/1.6.5.6.txt[1.6.5.6],
- link:RelNotes/1.6.5.5.txt[1.6.5.5],
- link:RelNotes/1.6.5.4.txt[1.6.5.4],
- link:RelNotes/1.6.5.3.txt[1.6.5.3],
- link:RelNotes/1.6.5.2.txt[1.6.5.2],
- link:RelNotes/1.6.5.1.txt[1.6.5.1],
- link:RelNotes/1.6.5.txt[1.6.5].
-
-* link:v1.6.4.5/git.html[documentation for release 1.6.4.5]
-
-* release notes for
- link:RelNotes/1.6.4.5.txt[1.6.4.5],
- link:RelNotes/1.6.4.4.txt[1.6.4.4],
- link:RelNotes/1.6.4.3.txt[1.6.4.3],
- link:RelNotes/1.6.4.2.txt[1.6.4.2],
- link:RelNotes/1.6.4.1.txt[1.6.4.1],
- link:RelNotes/1.6.4.txt[1.6.4].
-
-* link:v1.6.3.4/git.html[documentation for release 1.6.3.4]
-
-* release notes for
- link:RelNotes/1.6.3.4.txt[1.6.3.4],
- link:RelNotes/1.6.3.3.txt[1.6.3.3],
- link:RelNotes/1.6.3.2.txt[1.6.3.2],
- link:RelNotes/1.6.3.1.txt[1.6.3.1],
- link:RelNotes/1.6.3.txt[1.6.3].
-
-* release notes for
- link:RelNotes/1.6.2.5.txt[1.6.2.5],
- link:RelNotes/1.6.2.4.txt[1.6.2.4],
- link:RelNotes/1.6.2.3.txt[1.6.2.3],
- link:RelNotes/1.6.2.2.txt[1.6.2.2],
- link:RelNotes/1.6.2.1.txt[1.6.2.1],
- link:RelNotes/1.6.2.txt[1.6.2].
-
-* link:v1.6.1.3/git.html[documentation for release 1.6.1.3]
-
-* release notes for
- link:RelNotes/1.6.1.3.txt[1.6.1.3],
- link:RelNotes/1.6.1.2.txt[1.6.1.2],
- link:RelNotes/1.6.1.1.txt[1.6.1.1],
- link:RelNotes/1.6.1.txt[1.6.1].
-
-* link:v1.6.0.6/git.html[documentation for release 1.6.0.6]
-
-* release notes for
- link:RelNotes/1.6.0.6.txt[1.6.0.6],
- link:RelNotes/1.6.0.5.txt[1.6.0.5],
- link:RelNotes/1.6.0.4.txt[1.6.0.4],
- link:RelNotes/1.6.0.3.txt[1.6.0.3],
- link:RelNotes/1.6.0.2.txt[1.6.0.2],
- link:RelNotes/1.6.0.1.txt[1.6.0.1],
- link:RelNotes/1.6.0.txt[1.6.0].
-
-* link:v1.5.6.6/git.html[documentation for release 1.5.6.6]
-
-* release notes for
- link:RelNotes/1.5.6.6.txt[1.5.6.6],
- link:RelNotes/1.5.6.5.txt[1.5.6.5],
- link:RelNotes/1.5.6.4.txt[1.5.6.4],
- link:RelNotes/1.5.6.3.txt[1.5.6.3],
- link:RelNotes/1.5.6.2.txt[1.5.6.2],
- link:RelNotes/1.5.6.1.txt[1.5.6.1],
- link:RelNotes/1.5.6.txt[1.5.6].
-
-* link:v1.5.5.6/git.html[documentation for release 1.5.5.6]
-
-* release notes for
- link:RelNotes/1.5.5.6.txt[1.5.5.6],
- link:RelNotes/1.5.5.5.txt[1.5.5.5],
- link:RelNotes/1.5.5.4.txt[1.5.5.4],
- link:RelNotes/1.5.5.3.txt[1.5.5.3],
- link:RelNotes/1.5.5.2.txt[1.5.5.2],
- link:RelNotes/1.5.5.1.txt[1.5.5.1],
- link:RelNotes/1.5.5.txt[1.5.5].
-
-* link:v1.5.4.7/git.html[documentation for release 1.5.4.7]
-
-* release notes for
- link:RelNotes/1.5.4.7.txt[1.5.4.7],
- link:RelNotes/1.5.4.6.txt[1.5.4.6],
- link:RelNotes/1.5.4.5.txt[1.5.4.5],
- link:RelNotes/1.5.4.4.txt[1.5.4.4],
- link:RelNotes/1.5.4.3.txt[1.5.4.3],
- link:RelNotes/1.5.4.2.txt[1.5.4.2],
- link:RelNotes/1.5.4.1.txt[1.5.4.1],
- link:RelNotes/1.5.4.txt[1.5.4].
-
-* link:v1.5.3.8/git.html[documentation for release 1.5.3.8]
-
-* release notes for
- link:RelNotes/1.5.3.8.txt[1.5.3.8],
- link:RelNotes/1.5.3.7.txt[1.5.3.7],
- link:RelNotes/1.5.3.6.txt[1.5.3.6],
- link:RelNotes/1.5.3.5.txt[1.5.3.5],
- link:RelNotes/1.5.3.4.txt[1.5.3.4],
- link:RelNotes/1.5.3.3.txt[1.5.3.3],
- link:RelNotes/1.5.3.2.txt[1.5.3.2],
- link:RelNotes/1.5.3.1.txt[1.5.3.1],
- link:RelNotes/1.5.3.txt[1.5.3].
-
-* link:v1.5.2.5/git.html[documentation for release 1.5.2.5]
-
-* release notes for
- link:RelNotes/1.5.2.5.txt[1.5.2.5],
- link:RelNotes/1.5.2.4.txt[1.5.2.4],
- link:RelNotes/1.5.2.3.txt[1.5.2.3],
- link:RelNotes/1.5.2.2.txt[1.5.2.2],
- link:RelNotes/1.5.2.1.txt[1.5.2.1],
- link:RelNotes/1.5.2.txt[1.5.2].
-
-* link:v1.5.1.6/git.html[documentation for release 1.5.1.6]
-
-* release notes for
- link:RelNotes/1.5.1.6.txt[1.5.1.6],
- link:RelNotes/1.5.1.5.txt[1.5.1.5],
- link:RelNotes/1.5.1.4.txt[1.5.1.4],
- link:RelNotes/1.5.1.3.txt[1.5.1.3],
- link:RelNotes/1.5.1.2.txt[1.5.1.2],
- link:RelNotes/1.5.1.1.txt[1.5.1.1],
- link:RelNotes/1.5.1.txt[1.5.1].
-
-* link:v1.5.0.7/git.html[documentation for release 1.5.0.7]
-
-* release notes for
- link:RelNotes/1.5.0.7.txt[1.5.0.7],
- link:RelNotes/1.5.0.6.txt[1.5.0.6],
- link:RelNotes/1.5.0.5.txt[1.5.0.5],
- link:RelNotes/1.5.0.3.txt[1.5.0.3],
- link:RelNotes/1.5.0.2.txt[1.5.0.2],
- link:RelNotes/1.5.0.1.txt[1.5.0.1],
- link:RelNotes/1.5.0.txt[1.5.0].
-
-* documentation for release link:v1.4.4.4/git.html[1.4.4.4],
- link:v1.3.3/git.html[1.3.3],
- link:v1.2.6/git.html[1.2.6],
- link:v1.0.13/git.html[1.0.13].
-
-============
-
-endif::stalenotes[]
OPTIONS
-------
@@ -568,7 +75,8 @@ example the following invocations are equivalent:
Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets
`foo.bar` to the boolean true value (just like `[foo]bar` would in a
config file). Including the equals but with an empty value (like `git -c
-foo.bar= ...`) sets `foo.bar` to the empty string.
+foo.bar= ...`) sets `foo.bar` to the empty string which `git config
+--type=bool` will convert to `false`.
--exec-path[=<path>]::
Path to wherever your core Git programs are installed.
@@ -595,6 +103,7 @@ foo.bar= ...`) sets `foo.bar` to the empty string.
configuration options (see the "Configuration Mechanism" section
below).
+-P::
--no-pager::
Do not pipe Git output into a pager.
@@ -651,6 +160,20 @@ foo.bar= ...`) sets `foo.bar` to the empty string.
Add "icase" magic to all pathspec. This is equivalent to setting
the `GIT_ICASE_PATHSPECS` environment variable to `1`.
+--no-optional-locks::
+ Do not perform optional operations that require locks. This is
+ equivalent to setting the `GIT_OPTIONAL_LOCKS` to `0`.
+
+--list-cmds=group[,group...]::
+ List commands by group. This is an internal/experimental
+ option and may change or be removed in the future. Supported
+ groups are: builtins, parseopt (builtin commands that use
+ parse-options), main (all commands in libexec directory),
+ others (all other commands in `$PATH` that have git- prefix),
+ list-<category> (see categories in command-list.txt),
+ nohelpers (exclude helper commands), alias and config
+ (retrieve command list from config variable completion.commands)
+
GIT COMMANDS
------------
@@ -879,11 +402,11 @@ Git so take care if using a foreign front-end.
of Git object directories which can be used to search for Git
objects. New objects will not be written to these directories.
+
- Entries that begin with `"` (double-quote) will be interpreted
- as C-style quoted paths, removing leading and trailing
- double-quotes and respecting backslash escapes. E.g., the value
- `"path-with-\"-and-:-in-it":vanilla-path` has two paths:
- `path-with-"-and-:-in-it` and `vanilla-path`.
+Entries that begin with `"` (double-quote) will be interpreted
+as C-style quoted paths, removing leading and trailing
+double-quotes and respecting backslash escapes. E.g., the value
+`"path-with-\"-and-:-in-it":vanilla-path` has two paths:
+`path-with-"-and-:-in-it` and `vanilla-path`.
`GIT_DIR`::
If the `GIT_DIR` environment variable is set then it
@@ -1010,11 +533,10 @@ other
If either of these environment variables is set then 'git fetch'
and 'git push' will use the specified command instead of 'ssh'
when they need to connect to a remote system.
- The command will be given exactly two or four arguments: the
- 'username@host' (or just 'host') from the URL and the shell
- command to execute on that remote system, optionally preceded by
- `-p` (literally) and the 'port' from the URL when it specifies
- something other than the default SSH port.
+ The command-line parameters passed to the configured command are
+ determined by the ssh variant. See `ssh.variant` option in
+ linkgit:git-config[1] for details.
+
+
`$GIT_SSH_COMMAND` takes precedence over `$GIT_SSH`, and is interpreted
by the shell, which allows additional arguments to be included.
@@ -1077,12 +599,16 @@ trace messages into this file descriptor.
+
Alternatively, if the variable is set to an absolute path
(starting with a '/' character), Git will interpret this
-as a file path and will try to write the trace messages
-into it.
+as a file path and will try to append the trace messages
+to it.
+
Unsetting the variable, or setting it to empty, "0" or
"false" (case insensitive) disables trace messages.
+`GIT_TRACE_FSMONITOR`::
+ Enables trace messages for the filesystem monitor extension.
+ See `GIT_TRACE` for available trace output options.
+
`GIT_TRACE_PACK_ACCESS`::
Enables trace messages for all accesses to any packs. For each
access, the pack file name and an offset in the pack is
@@ -1131,6 +657,16 @@ of clones and fetches.
variable.
See `GIT_TRACE` for available trace output options.
+`GIT_TRACE_CURL_NO_DATA`::
+ When a curl trace is enabled (see `GIT_TRACE_CURL` above), do not dump
+ data (that is, only dump info lines and headers).
+
+`GIT_REDACT_COOKIES`::
+ This can be set to a comma-separated list of strings. When a curl trace
+ is enabled (see `GIT_TRACE_CURL` above), whenever a "Cookies:" header
+ sent by the client is dumped, values of cookies whose key is in that
+ list (case-sensitive) are redacted.
+
`GIT_LITERAL_PATHSPECS`::
Setting this variable to `1` will cause Git to treat all
pathspecs literally, rather than as glob patterns. For example,
@@ -1189,6 +725,47 @@ of clones and fetches.
which feed potentially-untrusted URLS to git commands. See
linkgit:git-config[1] for more details.
+`GIT_PROTOCOL`::
+ For internal use only. Used in handshaking the wire protocol.
+ Contains a colon ':' separated list of keys with optional values
+ 'key[=value]'. Presence of unknown keys and values must be
+ ignored.
+
+`GIT_OPTIONAL_LOCKS`::
+ If set to `0`, Git will complete any requested operation without
+ performing any optional sub-operations that require taking a lock.
+ For example, this will prevent `git status` from refreshing the
+ index as a side effect. This is useful for processes running in
+ the background which do not want to cause lock contention with
+ other operations on the repository. Defaults to `1`.
+
+`GIT_REDIRECT_STDIN`::
+`GIT_REDIRECT_STDOUT`::
+`GIT_REDIRECT_STDERR`::
+ Windows-only: allow redirecting the standard input/output/error
+ handles to paths specified by the environment variables. This is
+ particularly useful in multi-threaded applications where the
+ canonical way to pass standard handles via `CreateProcess()` is
+ not an option because it would require the handles to be marked
+ inheritable (and consequently *every* spawned process would
+ inherit them, possibly blocking regular Git operations). The
+ primary intended use case is to use named pipes for communication
+ (e.g. `\\.\pipe\my-git-stdin-123`).
++
+Two special values are supported: `off` will simply close the
+corresponding standard handle, and if `GIT_REDIRECT_STDERR` is
+`2>&1`, standard error will be redirected to the same handle as
+standard output.
+
+`GIT_PRINT_SHA1_ELLIPSIS` (deprecated)::
+ If set to `yes`, print an ellipsis following an
+ (abbreviated) SHA-1 value. This affects indications of
+ detached HEADs (linkgit:git-checkout[1]) and the raw
+ diff output (linkgit:git-diff[1]). Printing an
+ ellipsis in the cases mentioned is no longer considered
+ adequate and support for it is likely to be removed in the
+ foreseeable future (along with the variable).
+
Discussion[[Discussion]]
------------------------
@@ -1281,7 +858,12 @@ Reporting Bugs
Report bugs to the Git mailing list <git@vger.kernel.org> where the
development and maintenance is primarily done. You do not have to be
-subscribed to the list to send a message there.
+subscribed to the list to send a message there. See the list archive
+at https://public-inbox.org/git for previous bug reports and other
+discussions.
+
+Issues which are security relevant should be disclosed privately to
+the Git Security mailing list <git-security@googlegroups.com>.
SEE ALSO
--------
diff --git a/en/i18n.txt b/en/i18n.txt
index 2dd79db5cbf674d3eeeb70c78cc961d0b15503ab..7e36e5b55b1ab89ed67ca02f5327e928c853183d 100644
--- a/en/i18n.txt
+++ b/en/i18n.txt
@@ -42,11 +42,11 @@ mind.
+
------------
[i18n]
- commitencoding = ISO-8859-1
+ commitEncoding = ISO-8859-1
------------
+
Commit objects created with the above setting record the value
-of `i18n.commitencoding` in its `encoding` header. This is to
+of `i18n.commitEncoding` in its `encoding` header. This is to
help other people who look at them later. Lack of this header
implies that the commit log message is encoded in UTF-8.
@@ -54,15 +54,15 @@ implies that the commit log message is encoded in UTF-8.
`encoding` header of a commit object, and try to re-code the
log message into UTF-8 unless otherwise specified. You can
specify the desired output encoding with
- `i18n.logoutputencoding` in `.git/config` file, like this:
+ `i18n.logOutputEncoding` in `.git/config` file, like this:
+
------------
[i18n]
- logoutputencoding = ISO-8859-1
+ logOutputEncoding = ISO-8859-1
------------
+
If you do not have this configuration variable, the value of
-`i18n.commitencoding` is used instead.
+`i18n.commitEncoding` is used instead.
Note that we deliberately chose not to re-code the commit log
message when a commit is made to force UTF-8 at the commit
diff --git a/en/merge-config.txt b/en/merge-config.txt
deleted file mode 100644
index df3ea3779be369ce0f935cfac945e79f08ff4b5a..0000000000000000000000000000000000000000
--- a/en/merge-config.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-merge.conflictStyle::
- Specify the style in which conflicted hunks are written out to
- working tree files upon merge. The default is "merge", which
- shows a `<<<<<<<` conflict marker, changes made by one side,
- a `=======` marker, changes made by the other side, and then
- a `>>>>>>>` marker. An alternate style, "diff3", adds a `|||||||`
- marker and the original text before the `=======` marker.
-
-merge.defaultToUpstream::
- If merge is called without any commit argument, merge the upstream
- branches configured for the current branch by using their last
- observed values stored in their remote-tracking branches.
- The values of the `branch.<current branch>.merge` that name the
- branches at the remote named by `branch.<current branch>.remote`
- are consulted, and then they are mapped via `remote.<remote>.fetch`
- to their corresponding remote-tracking branches, and the tips of
- these tracking branches are merged.
-
-merge.ff::
- By default, Git does not create an extra merge commit when merging
- a commit that is a descendant of the current commit. Instead, the
- tip of the current branch is fast-forwarded. When set to `false`,
- this variable tells Git to create an extra merge commit in such
- a case (equivalent to giving the `--no-ff` option from the command
- line). When set to `only`, only such fast-forward merges are
- allowed (equivalent to giving the `--ff-only` option from the
- command line).
-
-include::fmt-merge-msg-config.txt[]
-
-merge.renameLimit::
- The number of files to consider when performing rename detection
- during a merge; if not specified, defaults to the value of
- diff.renameLimit.
-
-merge.renormalize::
- Tell Git that canonical representation of files in the
- repository has changed over time (e.g. earlier commits record
- text files with CRLF line endings, but recent ones use LF line
- endings). In such a repository, Git can convert the data
- recorded in commits to a canonical form before performing a
- merge to reduce unnecessary conflicts. For more information,
- see section "Merging branches with differing checkin/checkout
- attributes" in linkgit:gitattributes[5].
-
-merge.stat::
- Whether to print the diffstat between ORIG_HEAD and the merge result
- at the end of the merge. True by default.
-
-merge.tool::
- Controls which merge tool is used by linkgit:git-mergetool[1].
- The list below shows the valid built-in values.
- Any other value is treated as a custom merge tool and requires
- that a corresponding mergetool.<tool>.cmd variable is defined.
-
-include::mergetools-merge.txt[]
-
-merge.verbosity::
- Controls the amount of output shown by the recursive merge
- strategy. Level 0 outputs nothing except a final error
- message if conflicts were detected. Level 1 outputs only
- conflicts, 2 outputs conflicts and file changes. Level 5 and
- above outputs debugging information. The default is level 2.
- Can be overridden by the `GIT_MERGE_VERBOSITY` environment variable.
-
-merge.<driver>.name::
- Defines a human-readable name for a custom low-level
- merge driver. See linkgit:gitattributes[5] for details.
-
-merge.<driver>.driver::
- Defines the command that implements a custom low-level
- merge driver. See linkgit:gitattributes[5] for details.
-
-merge.<driver>.recursive::
- Names a low-level merge driver to be used when
- performing an internal merge between common ancestors.
- See linkgit:gitattributes[5] for details.
diff --git a/en/merge-options.txt b/en/merge-options.txt
index 5b4a62e93624bc8289c835631aab5d5f13dff708..63a3fc09548abe8d34faab98f183e1817b21b878 100644
--- a/en/merge-options.txt
+++ b/en/merge-options.txt
@@ -35,13 +35,20 @@ set to `no` at the beginning of them.
--no-ff::
Create a merge commit even when the merge resolves as a
fast-forward. This is the default behaviour when merging an
- annotated (and possibly signed) tag.
+ annotated (and possibly signed) tag that is not stored in
+ its natural place in 'refs/tags/' hierarchy.
--ff-only::
Refuse to merge and exit with a non-zero status unless the
- current `HEAD` is already up-to-date or the merge can be
+ current `HEAD` is already up to date or the merge can be
resolved as a fast-forward.
+-S[<keyid>]::
+--gpg-sign[=<keyid>]::
+ GPG-sign the resulting merge commit. The `keyid` argument is
+ optional and defaults to the committer identity; if specified,
+ it must be stuck to the option without a space.
+
--log[=<n>]::
--no-log::
In addition to branch names, populate the log message with
@@ -51,6 +58,16 @@ set to `no` at the beginning of them.
With --no-log do not list one-line descriptions from the
actual commits being merged.
+--signoff::
+--no-signoff::
+ Add Signed-off-by line by the committer at the end of the commit
+ log message. The meaning of a signoff depends on the project,
+ but it typically certifies that committer has
+ the rights to submit this work under the same license and
+ agrees to a Developer Certificate of Origin
+ (see http://developercertificate.org/ for more information).
++
+With --no-signoff do not add a Signed-off-by line.
--stat::
-n::
diff --git a/en/merge-strategies.txt b/en/merge-strategies.txt
index 2eb92b93274df9fb5002336114654fe869903808..aa66cbe41eaf070a74d98801ba973daeb8d15106 100644
--- a/en/merge-strategies.txt
+++ b/en/merge-strategies.txt
@@ -23,8 +23,9 @@ recursive::
causing mismerges by tests done on actual merge commits
taken from Linux 2.6 kernel development history.
Additionally this can detect and handle merges involving
- renames. This is the default merge strategy when
- pulling or merging one branch.
+ renames, but currently cannot make use of detected
+ copies. This is the default merge strategy when pulling
+ or merging one branch.
+
The 'recursive' strategy can take the following options:
@@ -39,7 +40,8 @@ even look at what the other tree contains at all. It discards everything
the other tree did, declaring 'our' history contains all that happened in it.
theirs;;
- This is the opposite of 'ours'.
+ This is the opposite of 'ours'; note that, unlike 'ours', there is
+ no 'theirs' merge strategy to confuse this merge option with.
patience;;
With this option, 'merge-recursive' spends a little extra time
@@ -57,11 +59,12 @@ diff-algorithm=[patience|minimal|histogram|myers];;
ignore-space-change;;
ignore-all-space;;
ignore-space-at-eol;;
+ignore-cr-at-eol;;
Treats lines with the indicated type of whitespace change as
unchanged for the sake of a three-way merge. Whitespace
changes mixed with other changes to a line are not ignored.
- See also linkgit:git-diff[1] `-b`, `-w`, and
- `--ignore-space-at-eol`.
+ See also linkgit:git-diff[1] `-b`, `-w`,
+ `--ignore-space-at-eol`, and `--ignore-cr-at-eol`.
+
* If 'their' version only introduces whitespace changes to a line,
'our' version is used;
@@ -82,12 +85,14 @@ no-renormalize;;
`merge.renormalize` configuration variable.
no-renames;;
- Turn off rename detection.
+ Turn off rename detection. This overrides the `merge.renames`
+ configuration variable.
See also linkgit:git-diff[1] `--no-renames`.
find-renames[=<n>];;
Turn on rename detection, optionally setting the similarity
- threshold. This is the default.
+ threshold. This is the default. This overrides the
+ 'merge.renames' configuration variable.
See also linkgit:git-diff[1] `--find-renames`.
rename-threshold=<n>;;
diff --git a/en/pretty-formats.txt b/en/pretty-formats.txt
index 47b286b33e4edd937fe6f7cbe727713e0e61e324..7bfffae7652815596dcc29962e67e22efcf3075b 100644
--- a/en/pretty-formats.txt
+++ b/en/pretty-formats.txt
@@ -134,6 +134,8 @@ The placeholders are:
- '%cI': committer date, strict ISO 8601 format
- '%d': ref names, like the --decorate option of linkgit:git-log[1]
- '%D': ref names without the " (", ")" wrapping.
+- '%S': ref name given on the command line by which the commit was reached
+ (like `git log --source`), only works with `git log`
- '%e': encoding
- '%s': subject
- '%f': sanitized subject line, suitable for a filename
@@ -153,6 +155,9 @@ endif::git-rev-list[]
and "N" for no signature
- '%GS': show the name of the signer for a signed commit
- '%GK': show the key used to sign a signed commit
+- '%GF': show the fingerprint of the key used to sign a signed commit
+- '%GP': show the fingerprint of the primary key whose subkey was used
+ to sign a signed commit
- '%gD': reflog selector, e.g., `refs/stash@{1}` or
`refs/stash@{2 minutes ago`}; the format follows the rules described
for the `-g` option. The portion before the `@` is the refname as
@@ -173,12 +178,17 @@ endif::git-rev-list[]
- '%Cblue': switch color to blue
- '%Creset': reset color
- '%C(...)': color specification, as described under Values in the
- "CONFIGURATION FILE" section of linkgit:git-config[1];
- adding `auto,` at the beginning will emit color only when colors are
- enabled for log output (by `color.diff`, `color.ui`, or `--color`, and
- respecting the `auto` settings of the former if we are going to a
- terminal). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring
- on the next placeholders until the color is switched again.
+ "CONFIGURATION FILE" section of linkgit:git-config[1].
+ By default, colors are shown only when enabled for log output (by
+ `color.diff`, `color.ui`, or `--color`, and respecting the `auto`
+ settings of the former if we are going to a terminal). `%C(auto,...)`
+ is accepted as a historical synonym for the default (e.g.,
+ `%C(auto,red)`). Specifying `%C(always,...)` will show the colors
+ even when color is not otherwise enabled (though consider
+ just using `--color=always` to enable color for the whole output,
+ including this format and anything else git might color). `auto`
+ alone (i.e. `%C(auto)`) will turn on auto coloring on the next
+ placeholders until the color is switched again.
- '%m': left (`<`), right (`>`) or boundary (`-`) mark
- '%n': newline
- '%%': a raw '%'
@@ -197,10 +207,15 @@ endif::git-rev-list[]
- '%>>(<N>)', '%>>|(<N>)': similar to '%>(<N>)', '%>|(<N>)'
respectively, except that if the next placeholder takes more spaces
than given and there are spaces on its left, use those spaces
-- '%><(<N>)', '%><|(<N>)': similar to '% <(<N>)', '%<|(<N>)'
+- '%><(<N>)', '%><|(<N>)': similar to '%<(<N>)', '%<|(<N>)'
respectively, but padding both sides (i.e. the text is centered)
--%(trailers): display the trailers of the body as interpreted by
- linkgit:git-interpret-trailers[1]
+- %(trailers[:options]): display the trailers of the body as interpreted
+ by linkgit:git-interpret-trailers[1]. The `trailers` string may be
+ followed by a colon and zero or more comma-separated options. If the
+ `only` option is given, omit non-trailer lines from the trailer block.
+ If the `unfold` option is given, behave as if interpret-trailer's
+ `--unfold` option was given. E.g., `%(trailers:only,unfold)` to do
+ both.
NOTE: Some placeholders may depend on other options given to the
revision traversal engine. For example, the `%g*` reflog options will
@@ -213,8 +228,8 @@ If you add a `+` (plus sign) after '%' of a placeholder, a line-feed
is inserted immediately before the expansion if and only if the
placeholder expands to a non-empty string.
-If you add a `-` (minus sign) after '%' of a placeholder, line-feeds that
-immediately precede the expansion are deleted if and only if the
+If you add a `-` (minus sign) after '%' of a placeholder, all consecutive
+line-feeds immediately preceding the expansion are deleted if and only if the
placeholder expands to an empty string.
If you add a ` ` (space) after '%' of a placeholder, a space
diff --git a/en/pull-fetch-param.txt b/en/pull-fetch-param.txt
index 1ebbf1d738403204b77a6b18547de25e94ab28be..7d3a60f5b9361cd46adc4f005694a52ed06fd1c1 100644
--- a/en/pull-fetch-param.txt
+++ b/en/pull-fetch-param.txt
@@ -23,19 +23,50 @@ ifdef::git-pull[]
endif::git-pull[]
+
The format of a <refspec> parameter is an optional plus
-`+`, followed by the source ref <src>, followed
+`+`, followed by the source <src>, followed
by a colon `:`, followed by the destination ref <dst>.
-The colon can be omitted when <dst> is empty.
+The colon can be omitted when <dst> is empty. <src> is
+typically a ref, but it can also be a fully spelled hex object
+name.
+
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`;
it requests fetching everything up to the given tag.
+
The remote ref that matches <src>
-is fetched, and if <dst> is not empty string, the local
-ref that matches it is fast-forwarded using <src>.
-If the optional plus `+` is used, the local ref
-is updated even if it does not result in a fast-forward
-update.
+is fetched, and if <dst> is not an empty string, an attempt
+is made to update the local ref that matches it.
++
+Whether that update is allowed without `--force` depends on the ref
+namespace it's being fetched to, the type of object being fetched, and
+whether the update is considered to be a fast-forward. Generally, the
+same rules apply for fetching as when pushing, see the `<refspec>...`
+section of linkgit:git-push[1] for what those are. Exceptions to those
+rules particular to 'git fetch' are noted below.
++
+Until Git version 2.20, and unlike when pushing with
+linkgit:git-push[1], any updates to `refs/tags/*` would be accepted
+without `+` in the refspec (or `--force`). When fetching, we promiscuously
+considered all tag updates from a remote to be forced fetches. Since
+Git version 2.20, fetching to update `refs/tags/*` works the same way
+as when pushing. I.e. any updates will be rejected without `+` in the
+refspec (or `--force`).
++
+Unlike when pushing with linkgit:git-push[1], any updates outside of
+`refs/{tags,heads}/*` will be accepted without `+` in the refspec (or
+`--force`), whether that's swapping e.g. a tree object for a blob, or
+a commit for another commit that's doesn't have the previous commit as
+an ancestor etc.
++
+Unlike when pushing with linkgit:git-push[1], there is no
+configuration which'll amend these rules, and nothing like a
+`pre-fetch` hook analogous to the `pre-receive` hook.
++
+As with pushing with linkgit:git-push[1], all of the rules described
+above about what's not allowed as an update can be overridden by
+adding an the optional leading `+` to a refspec (or using `--force`
+command line option). The only exception to this is that no amount of
+forcing will make the `refs/heads/*` namespace accept a non-commit
+object.
+
[NOTE]
When the remote branch you want to fetch is known to
diff --git a/en/rev-list-options.txt b/en/rev-list-options.txt
index a02f7324c01ee5811441d2a6dcb93aafd892298c..cad711ce0ac060d9356e49599ffc13d130fc593c 100644
--- a/en/rev-list-options.txt
+++ b/en/rev-list-options.txt
@@ -13,8 +13,6 @@ has a line that matches `<pattern>`), unless otherwise noted.
Note that these are applied before commit
ordering and formatting options, such as `--reverse`.
---
-
-<number>::
-n <number>::
--max-count=<number>::
@@ -91,9 +89,14 @@ endif::git-rev-list[]
Consider the limiting patterns to be fixed strings (don't interpret
pattern as a regular expression).
+-P::
--perl-regexp::
- Consider the limiting patterns to be Perl-compatible regular expressions.
- Requires libpcre to be compiled in.
+ Consider the limiting patterns to be Perl-compatible regular
+ expressions.
++
+Support for these types of regular expressions is an optional
+compile-time dependency. If Git wasn't compiled with support for them
+providing this option will cause it to die.
--remove-empty::
Stop when a given path disappears from the tree.
@@ -179,6 +182,14 @@ explicitly.
Pretend as if all objects mentioned by reflogs are listed on the
command line as `<commit>`.
+--single-worktree::
+ By default, all working trees will be examined by the
+ following options when there are more than one (see
+ linkgit:git-worktree[1]): `--all`, `--reflog` and
+ `--indexed-objects`.
+ This option forces them to examine the current working tree
+ only.
+
--ignore-missing::
Upon seeing an invalid object name in the input, pretend as if
the bad input was not given.
@@ -259,13 +270,13 @@ depending on a few rules:
+
--
1. If the starting point is specified as `ref@{Nth}`, show the index
-format.
+ format.
+
2. If the starting point was specified as `ref@{now}`, show the
-timestamp format.
+ timestamp format.
+
3. If neither was used, but `--date` was given on the command line, show
-the timestamp in the format requested by `--date`.
+ the timestamp in the format requested by `--date`.
+
4. Otherwise, show the index format.
--
@@ -295,8 +306,6 @@ ifdef::git-rev-list[]
`<header>` text will be printed with each progress update.
endif::git-rev-list[]
---
-
History Simplification
~~~~~~~~~~~~~~~~~~~~~~
@@ -673,6 +682,11 @@ ifdef::git-rev-list[]
all object IDs which I need to download if I have the commit
object _bar_ but not _foo_''.
+--in-commit-order::
+ Print tree and blob ids in order of the commits. The tree
+ and blob ids are printed after they are first referenced
+ by a commit.
+
--objects-edge::
Similar to `--objects`, but also print the IDs of excluded
commits prefixed with a ``-'' character. This is used by
@@ -693,6 +707,68 @@ ifdef::git-rev-list[]
--unpacked::
Only useful with `--objects`; print the object IDs that are not
in packs.
+
+--filter=<filter-spec>::
+ Only useful with one of the `--objects*`; omits objects (usually
+ blobs) from the list of printed objects. The '<filter-spec>'
+ may be one of the following:
++
+The form '--filter=blob:none' omits all blobs.
++
+The form '--filter=blob:limit=<n>[kmg]' omits blobs larger than n bytes
+or units. n may be zero. The suffixes k, m, and g can be used to name
+units in KiB, MiB, or GiB. For example, 'blob:limit=1k' is the same
+as 'blob:limit=1024'.
++
+The form '--filter=sparse:oid=<blob-ish>' uses a sparse-checkout
+specification contained in the blob (or blob-expression) '<blob-ish>'
+to omit blobs that would not be not required for a sparse checkout on
+the requested refs.
++
+The form '--filter=sparse:path=<path>' similarly uses a sparse-checkout
+specification contained in <path>.
++
+The form '--filter=tree:<depth>' omits all blobs and trees whose depth
+from the root tree is >= <depth> (minimum depth if an object is located
+at multiple depths in the commits traversed). <depth>=0 will not include
+any trees or blobs unless included explicitly in the command-line (or
+standard input when --stdin is used). <depth>=1 will include only the
+tree and blobs which are referenced directly by a commit reachable from
+<commit> or an explicitly-given object. <depth>=2 is like <depth>=1
+while also including trees and blobs one more level removed from an
+explicitly-given commit or tree.
+
+--no-filter::
+ Turn off any previous `--filter=` argument.
+
+--filter-print-omitted::
+ Only useful with `--filter=`; prints a list of the objects omitted
+ by the filter. Object IDs are prefixed with a ``~'' character.
+
+--missing=<missing-action>::
+ A debug option to help with future "partial clone" development.
+ This option specifies how missing objects are handled.
++
+The form '--missing=error' requests that rev-list stop with an error if
+a missing object is encountered. This is the default action.
++
+The form '--missing=allow-any' will allow object traversal to continue
+if a missing object is encountered. Missing objects will silently be
+omitted from the results.
++
+The form '--missing=allow-promisor' is like 'allow-any', but will only
+allow object traversal to continue for EXPECTED promisor missing objects.
+Unexpected missing objects will raise an error.
++
+The form '--missing=print' is like 'allow-any', but will also print a
+list of the missing objects. Object IDs are prefixed with a ``?'' character.
+
+--exclude-promisor-objects::
+ (For internal use only.) Prefilter object traversal at
+ promisor boundary. This is used with partial clone. This is
+ stronger than `--missing=allow-promisor` because it limits the
+ traversal, rather than just silencing errors about missing
+ objects.
endif::git-rev-list[]
--no-walk[=(sorted|unsorted)]::
@@ -760,11 +836,19 @@ Note that the `-local` option does not affect the seconds-since-epoch
value (which is always measured in UTC), but does switch the accompanying
timezone value.
+
+`--date=human` shows the timezone if the timezone does not match the
+current time-zone, and doesn't print the whole date if that matches
+(ie skip printing year for dates that are "this year", but also skip
+the whole date itself if it's in the last few days and we can just say
+what weekday it was). For older dates the hour and minute is also
+omitted.
++
`--date=unix` shows the date as a Unix epoch timestamp (seconds since
1970). As with `--raw`, this is always in UTC and therefore `-local`
has no effect.
+
-`--date=format:...` feeds the format `...` to your system `strftime`.
+`--date=format:...` feeds the format `...` to your system `strftime`,
+except for %z and %Z, which are handled internally.
Use `--date=format:%c` to show the date in your system locale's
preferred format. See the `strftime` manual for a complete list of
format placeholders. When using `-local`, the correct syntax is
@@ -785,11 +869,11 @@ endif::git-rev-list[]
--parents::
Print also the parents of the commit (in the form "commit parent...").
- Also enables parent rewriting, see 'History Simplification' below.
+ Also enables parent rewriting, see 'History Simplification' above.
--children::
Print also the children of the commit (in the form "commit child...").
- Also enables parent rewriting, see 'History Simplification' below.
+ Also enables parent rewriting, see 'History Simplification' above.
ifdef::git-rev-list[]
--timestamp::
@@ -832,7 +916,7 @@ you would get an output like this:
to be drawn properly.
Cannot be combined with `--no-walk`.
+
-This enables parent rewriting, see 'History Simplification' below.
+This enables parent rewriting, see 'History Simplification' above.
+
This implies the `--topo-order` option by default, but the
`--date-order` option may also be specified.
diff --git a/en/revisions.txt b/en/revisions.txt
index ba11b9c95e3a6efef461e5cadc4834ce232896b1..72daa20e76fa0a0c10feaf37f927797ad1445934 100644
--- a/en/revisions.txt
+++ b/en/revisions.txt
@@ -7,6 +7,10 @@ syntax. Here are various ways to spell object names. The
ones listed near the end of this list name trees and
blobs contained in a commit.
+NOTE: This document shows the "raw" syntax as seen by git. The shell
+and other UIs might require additional quoting to protect special
+characters and to avoid word splitting.
+
'<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e'::
The full SHA-1 object name (40-byte hexadecimal string), or
a leading substring that is unique within the repository.
@@ -96,7 +100,8 @@ some output processing may assume ref names in UTF-8.
refers to the branch that the branch specified by branchname is set to build on
top of (configured with `branch.<name>.remote` and
`branch.<name>.merge`). A missing branchname defaults to the
- current one.
+ current one. These suffixes are also accepted when spelled in uppercase, and
+ they mean the same thing no matter the case.
'<branchname>@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
The suffix '@\{push}' reports the branch "where we would push to" if
@@ -122,6 +127,9 @@ refs/remotes/myfork/mybranch
Note in the example that we set up a triangular workflow, where we pull
from one location and push to another. In a non-triangular workflow,
'@\{push}' is the same as '@\{upstream}', and there is no need for it.
++
+This suffix is also accepted when spelled in uppercase, and means the same
+thing no matter the case.
'<rev>{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
A suffix '{caret}' to a revision parameter means the first parent of
@@ -176,12 +184,15 @@ existing tag object.
A colon, followed by a slash, followed by a text, names
a commit whose commit message matches the specified regular expression.
This name returns the youngest matching commit which is
- reachable from any ref. The regular expression can match any part of the
+ reachable from any ref, including HEAD.
+ The regular expression can match any part of the
commit message. To match messages starting with a string, one can use
e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what
is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a
literal '!' character, followed by 'foo'. Any other sequence beginning with
':/!' is reserved for now.
+ Depending on the given text, the shell's word splitting rules might
+ require additional quoting.
'<rev>:<path>', e.g. 'HEAD:README', ':README', 'master:./README'::
A suffix ':' followed by a path names the blob or tree
@@ -267,7 +278,7 @@ The '..' (two-dot) Range Notation::
for commits that are reachable from r2 excluding those that are reachable
from r1 by '{caret}r1 r2' and it can be written as 'r1..r2'.
-The '...' (three dot) Symmetric Difference Notation::
+The '...' (three-dot) Symmetric Difference Notation::
A similar notation 'r1\...r2' is called symmetric difference
of 'r1' and 'r2' and is defined as
'r1 r2 --not $(git merge-base --all r1 r2)'.
@@ -291,7 +302,7 @@ The 'r1{caret}@' notation means all parents of 'r1'.
The 'r1{caret}!' notation includes commit 'r1' but excludes all of its parents.
By itself, this notation denotes the single commit 'r1'.
-The '<rev>{caret}-{<n>}' notation includes '<rev>' but excludes the <n>th
+The '<rev>{caret}-<n>' notation includes '<rev>' but excludes the <n>th
parent (i.e. a shorthand for '<rev>{caret}<n>..<rev>'), with '<n>' = 1 if
not given. This is typically useful for merge commits where you
can just pass '<commit>{caret}-' to get all the commits in the branch
@@ -333,7 +344,7 @@ Revision Range Summary
as giving commit '<rev>' and then all its parents prefixed with
'{caret}' to exclude them (and their ancestors).
-'<rev>{caret}-{<n>}', e.g. 'HEAD{caret}-, HEAD{caret}-2'::
+'<rev>{caret}-<n>', e.g. 'HEAD{caret}-, HEAD{caret}-2'::
Equivalent to '<rev>{caret}<n>..<rev>', with '<n>' = 1 if not
given.
@@ -341,6 +352,7 @@ Here are a handful of examples using the Loeliger illustration above,
with each step in the notation's expansion and selection carefully
spelt out:
+....
Args Expanded arguments Selected commits
D G H D
D F G H I J D F
@@ -363,3 +375,4 @@ spelt out:
= B ^B^1 ^B^2 ^B^3
= B ^D ^E ^F B
F^! D = F ^I ^J D G H D F
+....
diff --git a/scripts/update-sources.sh b/scripts/update-sources.sh
index 99b043141a33a406f64d6661717c6058ae5e0053..247207ee218385702072b836c4ba5fce157a5503 100755
--- a/scripts/update-sources.sh
+++ b/scripts/update-sources.sh
@@ -2,7 +2,7 @@
for f in $(cat sources.txt)
do
- ln ../$f en/$f
+ ln -f ../$f en/$f
done
cp ../../GIT-VERSION-FILE .
diff --git a/sources.txt b/sources.txt
index 84047f5dbe2a2f89b884e1c2cd938368d7fa53b0..ed4055ea42998675b77c152f612a8300009a10c3 100644
--- a/sources.txt
+++ b/sources.txt
@@ -10,12 +10,10 @@ cmds-synchelpers.txt
cmds-synchingrepositories.txt
config.txt
date-formats.txt
-diff-config.txt
diff-format.txt
diff-generate-patch.txt
diff-options.txt
fetch-options.txt
-fmt-merge-msg-config.txt
git-add.txt
git-am.txt
git-annotate.txt
@@ -167,7 +165,6 @@ git-write-tree.txt
i18n.txt
line-range-format.txt
mailmap.txt
-merge-config.txt
merge-options.txt
merge-strategies.txt
mergetools-merge.txt