branch of the `git.git` repository.
Documentation for older releases are available here:
-* link:v2.5.5/git.html[documentation for release 2.5.5]
+* 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.6/git.html[documentation for release 2.5.6]
+
+* release notes for
+ link:RelNotes/2.5.6.txt[2.5.6],
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.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]
+* link:v2.4.12/git.html[documentation for release 2.4.12]
* release notes for
+ link:RelNotes/2.4.12.txt[2.4.12],
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],
Enables trace messages for all packets coming in or out of a
given program. This can help with debugging object negotiation
or other protocol issues. Tracing is turned off at a packet
- starting with "PACK".
+ starting with "PACK" (but see 'GIT_TRACE_PACKFILE' below).
See 'GIT_TRACE' for available trace output options.
+'GIT_TRACE_PACKFILE'::
+ Enables tracing of packfiles sent or received by a
+ given program. Unlike other trace output, this trace is
+ verbatim: no headers, and no quoting of binary data. You almost
+ certainly want to direct into a file (e.g.,
+ `GIT_TRACE_PACKFILE=/tmp/my.pack`) rather than displaying it on
+ the terminal or mixing it with other trace output.
++
+Note that this is currently only implemented for the client side
+of clones and fetches.
+
'GIT_TRACE_PERFORMANCE'::
Enables performance related trace messages, e.g. total execution
time of each Git command.
cloning of shallow repositories.
See 'GIT_TRACE' for available trace output options.
-GIT_LITERAL_PATHSPECS::
+'GIT_LITERAL_PATHSPECS'::
Setting this variable to `1` will cause Git to treat all
pathspecs literally, rather than as glob patterns. For example,
running `GIT_LITERAL_PATHSPECS=1 git log -- '*.c'` will search
literal paths to Git (e.g., paths previously given to you by
`git ls-tree`, `--raw` diff output, etc).
-GIT_GLOB_PATHSPECS::
+'GIT_GLOB_PATHSPECS'::
Setting this variable to `1` will cause Git to treat all
pathspecs as glob patterns (aka "glob" magic).
-GIT_NOGLOB_PATHSPECS::
+'GIT_NOGLOB_PATHSPECS'::
Setting this variable to `1` will cause Git to treat all
pathspecs as literal (aka "literal" magic).
-GIT_ICASE_PATHSPECS::
+'GIT_ICASE_PATHSPECS'::
Setting this variable to `1` will cause Git to treat all
pathspecs as case-insensitive.
variable when it is invoked as the top level command by the
end user, to be recorded in the body of the reflog.
-`GIT_REF_PARANOIA`::
+'GIT_REF_PARANOIA'::
If set to `1`, include broken or badly named refs when iterating
over lists of refs. In a normal, non-corrupted repository, this
does nothing. However, enabling it may help git to detect and
an operation has touched every ref (e.g., because you are
cloning a repository to make a backup).
-`GIT_ALLOW_PROTOCOL`::
+'GIT_ALLOW_PROTOCOL'::
If set, provide a colon-separated list of protocols which are
allowed to be used with fetch/push/clone. This is useful to
restrict recursive submodule initialization from an untrusted