6 git - the stupid content tracker
12 'git' [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
13 [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
14 [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
15 [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
16 [--super-prefix=<path>] [--config-env=<name>=<envvar>]
21 Git is a fast, scalable, distributed revision control system with an
22 unusually rich command set that provides both high-level operations
23 and full access to internals.
25 See linkgit:gittutorial[7] to get started, then see
26 linkgit:giteveryday[7] for a useful minimum set of
27 commands. The link:user-manual.html[Git User's Manual] has a more
28 in-depth introduction.
30 After you mastered the basic concepts, you can come back to this
31 page to learn what commands Git offers. You can learn more about
32 individual Git commands with "git help command". linkgit:gitcli[7]
33 manual page gives you an overview of the command-line command syntax.
35 A formatted and hyperlinked copy of the latest Git documentation
36 can be viewed at https://git.github.io/htmldocs/git.html
37 or https://git-scm.com/docs.
44 Prints the Git suite version that the 'git' program came from.
46 This option is internally converted to `git version ...` and accepts
47 the same options as the linkgit:git-version[1] command. If `--help` is
48 also given, it takes precedence over `--version`.
52 Prints the synopsis and a list of the most commonly used
53 commands. If the option `--all` or `-a` is given then all
54 available commands are printed. If a Git command is named this
55 option will bring up the manual page for that command.
57 Other options are available to control how the manual page is
58 displayed. See linkgit:git-help[1] for more information,
59 because `git --help ...` is converted internally into `git
63 Run as if git was started in '<path>' instead of the current working
64 directory. When multiple `-C` options are given, each subsequent
65 non-absolute `-C <path>` is interpreted relative to the preceding `-C
66 <path>`. If '<path>' is present but empty, e.g. `-C ""`, then the
67 current working directory is left unchanged.
69 This option affects options that expect path name like `--git-dir` and
70 `--work-tree` in that their interpretations of the path names would be
71 made relative to the working directory caused by the `-C` option. For
72 example the following invocations are equivalent:
74 git --git-dir=a.git --work-tree=b -C c status
75 git --git-dir=c/a.git --work-tree=c/b status
78 Pass a configuration parameter to the command. The value
79 given will override values from configuration files.
80 The <name> is expected in the same format as listed by
81 'git config' (subkeys separated by dots).
83 Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets
84 `foo.bar` to the boolean true value (just like `[foo]bar` would in a
85 config file). Including the equals but with an empty value (like `git -c
86 foo.bar= ...`) sets `foo.bar` to the empty string which `git config
87 --type=bool` will convert to `false`.
89 --config-env=<name>=<envvar>::
90 Like `-c <name>=<value>`, give configuration variable
91 '<name>' a value, where <envvar> is the name of an
92 environment variable from which to retrieve the value. Unlike
93 `-c` there is no shortcut for directly setting the value to an
94 empty string, instead the environment variable itself must be
95 set to the empty string. It is an error if the `<envvar>` does not exist
96 in the environment. `<envvar>` may not contain an equals sign
97 to avoid ambiguity with `<name>` containing one.
99 This is useful for cases where you want to pass transitory
100 configuration options to git, but are doing so on OS's where
101 other processes might be able to read your cmdline
102 (e.g. `/proc/self/cmdline`), but not your environ
103 (e.g. `/proc/self/environ`). That behavior is the default on
104 Linux, but may not be on your system.
106 Note that this might add security for variables such as
107 `http.extraHeader` where the sensitive information is part of
108 the value, but not e.g. `url.<base>.insteadOf` where the
109 sensitive information can be part of the key.
111 --exec-path[=<path>]::
112 Path to wherever your core Git programs are installed.
113 This can also be controlled by setting the GIT_EXEC_PATH
114 environment variable. If no path is given, 'git' will print
115 the current setting and then exit.
118 Print the path, without trailing slash, where Git's HTML
119 documentation is installed and exit.
122 Print the manpath (see `man(1)`) for the man pages for
123 this version of Git and exit.
126 Print the path where the Info files documenting this
127 version of Git are installed and exit.
131 Pipe all output into 'less' (or if set, $PAGER) if standard
132 output is a terminal. This overrides the `pager.<cmd>`
133 configuration options (see the "Configuration Mechanism" section
138 Do not pipe Git output into a pager.
141 Set the path to the repository (".git" directory). This can also be
142 controlled by setting the `GIT_DIR` environment variable. It can be
143 an absolute path or relative path to current working directory.
145 Specifying the location of the ".git" directory using this
146 option (or `GIT_DIR` environment variable) turns off the
147 repository discovery that tries to find a directory with
148 ".git" subdirectory (which is how the repository and the
149 top-level of the working tree are discovered), and tells Git
150 that you are at the top level of the working tree. If you
151 are not at the top-level directory of the working tree, you
152 should tell Git where the top-level of the working tree is,
153 with the `--work-tree=<path>` option (or `GIT_WORK_TREE`
154 environment variable)
156 If you just want to run git as if it was started in `<path>` then use
160 Set the path to the working tree. It can be an absolute path
161 or a path relative to the current working directory.
162 This can also be controlled by setting the GIT_WORK_TREE
163 environment variable and the core.worktree configuration
164 variable (see core.worktree in linkgit:git-config[1] for a
165 more detailed discussion).
168 Set the Git namespace. See linkgit:gitnamespaces[7] for more
169 details. Equivalent to setting the `GIT_NAMESPACE` environment
172 --super-prefix=<path>::
173 Currently for internal use only. Set a prefix which gives a path from
174 above a repository down to its root. One use is to give submodules
175 context about the superproject that invoked it.
178 Treat the repository as a bare repository. If GIT_DIR
179 environment is not set, it is set to the current working
182 --no-replace-objects::
183 Do not use replacement refs to replace Git objects. See
184 linkgit:git-replace[1] for more information.
186 --literal-pathspecs::
187 Treat pathspecs literally (i.e. no globbing, no pathspec magic).
188 This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment
192 Add "glob" magic to all pathspec. This is equivalent to setting
193 the `GIT_GLOB_PATHSPECS` environment variable to `1`. Disabling
194 globbing on individual pathspecs can be done using pathspec
198 Add "literal" magic to all pathspec. This is equivalent to setting
199 the `GIT_NOGLOB_PATHSPECS` environment variable to `1`. Enabling
200 globbing on individual pathspecs can be done using pathspec
204 Add "icase" magic to all pathspec. This is equivalent to setting
205 the `GIT_ICASE_PATHSPECS` environment variable to `1`.
207 --no-optional-locks::
208 Do not perform optional operations that require locks. This is
209 equivalent to setting the `GIT_OPTIONAL_LOCKS` to `0`.
211 --list-cmds=group[,group...]::
212 List commands by group. This is an internal/experimental
213 option and may change or be removed in the future. Supported
214 groups are: builtins, parseopt (builtin commands that use
215 parse-options), main (all commands in libexec directory),
216 others (all other commands in `$PATH` that have git- prefix),
217 list-<category> (see categories in command-list.txt),
218 nohelpers (exclude helper commands), alias and config
219 (retrieve command list from config variable completion.commands)
224 We divide Git into high level ("porcelain") commands and low level
225 ("plumbing") commands.
227 High-level commands (porcelain)
228 -------------------------------
230 We separate the porcelain commands into the main commands and some
231 ancillary user utilities.
233 Main porcelain commands
234 ~~~~~~~~~~~~~~~~~~~~~~~
236 include::cmds-mainporcelain.txt[]
242 include::cmds-ancillarymanipulators.txt[]
246 include::cmds-ancillaryinterrogators.txt[]
249 Interacting with Others
250 ~~~~~~~~~~~~~~~~~~~~~~~
252 These commands are to interact with foreign SCM and with other
253 people via patch over e-mail.
255 include::cmds-foreignscminterface.txt[]
257 Reset, restore and revert
258 ~~~~~~~~~~~~~~~~~~~~~~~~~
259 There are three commands with similar names: `git reset`,
260 `git restore` and `git revert`.
262 * linkgit:git-revert[1] is about making a new commit that reverts the
263 changes made by other commits.
265 * linkgit:git-restore[1] is about restoring files in the working tree
266 from either the index or another commit. This command does not
267 update your branch. The command can also be used to restore files in
268 the index from another commit.
270 * linkgit:git-reset[1] is about updating your branch, moving the tip
271 in order to add or remove commits from the branch. This operation
272 changes the commit history.
274 `git reset` can also be used to restore the index, overlapping with
278 Low-level commands (plumbing)
279 -----------------------------
281 Although Git includes its
282 own porcelain layer, its low-level commands are sufficient to support
283 development of alternative porcelains. Developers of such porcelains
284 might start by reading about linkgit:git-update-index[1] and
285 linkgit:git-read-tree[1].
287 The interface (input, output, set of options and the semantics)
288 to these low-level commands are meant to be a lot more stable
289 than Porcelain level commands, because these commands are
290 primarily for scripted use. The interface to Porcelain commands
291 on the other hand are subject to change in order to improve the
294 The following description divides
295 the low-level commands into commands that manipulate objects (in
296 the repository, index, and working tree), commands that interrogate and
297 compare objects, and commands that move objects and references between
301 Manipulation commands
302 ~~~~~~~~~~~~~~~~~~~~~
304 include::cmds-plumbingmanipulators.txt[]
307 Interrogation commands
308 ~~~~~~~~~~~~~~~~~~~~~~
310 include::cmds-plumbinginterrogators.txt[]
312 In general, the interrogate commands do not touch the files in
319 include::cmds-synchingrepositories.txt[]
321 The following are helper commands used by the above; end users
322 typically do not use them directly.
324 include::cmds-synchelpers.txt[]
327 Internal helper commands
328 ~~~~~~~~~~~~~~~~~~~~~~~~
330 These are internal helper commands used by other commands; end
331 users typically do not use them directly.
333 include::cmds-purehelpers.txt[]
338 The following documentation pages are guides about Git concepts.
340 include::cmds-guide.txt[]
343 Configuration Mechanism
344 -----------------------
346 Git uses a simple text format to store customizations that are per
347 repository and are per user. Such a configuration file may look
352 # A '#' or ';' character indicates a comment.
357 ; Don't trust file modes
362 name = "Junio C Hamano"
363 email = "gitster@pobox.com"
367 Various commands read from the configuration file and adjust
368 their operation accordingly. See linkgit:git-config[1] for a
369 list and more details about the configuration mechanism.
372 Identifier Terminology
373 ----------------------
375 Indicates the object name for any type of object.
378 Indicates a blob object name.
381 Indicates a tree object name.
384 Indicates a commit object name.
387 Indicates a tree, commit or tag object name. A
388 command that takes a <tree-ish> argument ultimately wants to
389 operate on a <tree> object but automatically dereferences
390 <commit> and <tag> objects that point at a <tree>.
393 Indicates a commit or tag object name. A
394 command that takes a <commit-ish> argument ultimately wants to
395 operate on a <commit> object but automatically dereferences
396 <tag> objects that point at a <commit>.
399 Indicates that an object type is required.
400 Currently one of: `blob`, `tree`, `commit`, or `tag`.
403 Indicates a filename - almost always relative to the
404 root of the tree structure `GIT_INDEX_FILE` describes.
408 Any Git command accepting any <object> can also use the following
412 indicates the head of the current branch.
416 (i.e. a `refs/tags/<tag>` reference).
420 (i.e. a `refs/heads/<head>` reference).
422 For a more complete list of ways to spell object names, see
423 "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
426 File/Directory Structure
427 ------------------------
429 Please see the linkgit:gitrepository-layout[5] document.
431 Read linkgit:githooks[5] for more details about each hook.
433 Higher level SCMs may provide and manage additional information in the
439 Please see linkgit:gitglossary[7].
442 Environment Variables
443 ---------------------
444 Various Git commands use the following environment variables:
448 These environment variables apply to 'all' core Git commands. Nb: it
449 is worth noting that they may be used/overridden by SCMS sitting above
450 Git so take care if using a foreign front-end.
453 This environment allows the specification of an alternate
454 index file. If not specified, the default of `$GIT_DIR/index`
457 `GIT_INDEX_VERSION`::
458 This environment variable allows the specification of an index
459 version for new repositories. It won't affect existing index
460 files. By default index file version 2 or 3 is used. See
461 linkgit:git-update-index[1] for more information.
463 `GIT_OBJECT_DIRECTORY`::
464 If the object storage directory is specified via this
465 environment variable then the sha1 directories are created
466 underneath - otherwise the default `$GIT_DIR/objects`
469 `GIT_ALTERNATE_OBJECT_DIRECTORIES`::
470 Due to the immutable nature of Git objects, old objects can be
471 archived into shared, read-only directories. This variable
472 specifies a ":" separated (on Windows ";" separated) list
473 of Git object directories which can be used to search for Git
474 objects. New objects will not be written to these directories.
476 Entries that begin with `"` (double-quote) will be interpreted
477 as C-style quoted paths, removing leading and trailing
478 double-quotes and respecting backslash escapes. E.g., the value
479 `"path-with-\"-and-:-in-it":vanilla-path` has two paths:
480 `path-with-"-and-:-in-it` and `vanilla-path`.
483 If the `GIT_DIR` environment variable is set then it
484 specifies a path to use instead of the default `.git`
485 for the base of the repository.
486 The `--git-dir` command-line option also sets this value.
489 Set the path to the root of the working tree.
490 This can also be controlled by the `--work-tree` command-line
491 option and the core.worktree configuration variable.
494 Set the Git namespace; see linkgit:gitnamespaces[7] for details.
495 The `--namespace` command-line option also sets this value.
497 `GIT_CEILING_DIRECTORIES`::
498 This should be a colon-separated list of absolute paths. If
499 set, it is a list of directories that Git should not chdir up
500 into while looking for a repository directory (useful for
501 excluding slow-loading network directories). It will not
502 exclude the current working directory or a GIT_DIR set on the
503 command line or in the environment. Normally, Git has to read
504 the entries in this list and resolve any symlink that
505 might be present in order to compare them with the current
506 directory. However, if even this access is slow, you
507 can add an empty entry to the list to tell Git that the
508 subsequent entries are not symlinks and needn't be resolved;
510 `GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink`.
512 `GIT_DISCOVERY_ACROSS_FILESYSTEM`::
513 When run in a directory that does not have ".git" repository
514 directory, Git tries to find such a directory in the parent
515 directories to find the top of the working tree, but by default it
516 does not cross filesystem boundaries. This environment variable
517 can be set to true to tell Git not to stop at filesystem
518 boundaries. Like `GIT_CEILING_DIRECTORIES`, this will not affect
519 an explicit repository directory set via `GIT_DIR` or on the
523 If this variable is set to a path, non-worktree files that are
524 normally in $GIT_DIR will be taken from this path
525 instead. Worktree-specific files such as HEAD or index are
526 taken from $GIT_DIR. See linkgit:gitrepository-layout[5] and
527 linkgit:git-worktree[1] for
528 details. This variable has lower precedence than other path
529 variables such as GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY...
532 If this variable is set, the default hash algorithm for new
533 repositories will be set to this value. This value is currently
534 ignored when cloning; the setting of the remote repository
535 is used instead. The default is "sha1". THIS VARIABLE IS
536 EXPERIMENTAL! See `--object-format` in linkgit:git-init[1].
541 The human-readable name used in the author identity when creating commit or
542 tag objects, or when writing reflogs. Overrides the `user.name` and
543 `author.name` configuration settings.
546 The email address used in the author identity when creating commit or
547 tag objects, or when writing reflogs. Overrides the `user.email` and
548 `author.email` configuration settings.
551 The date used for the author identity when creating commit or tag objects, or
552 when writing reflogs. See linkgit:git-commit[1] for valid formats.
554 `GIT_COMMITTER_NAME`::
555 The human-readable name used in the committer identity when creating commit or
556 tag objects, or when writing reflogs. Overrides the `user.name` and
557 `committer.name` configuration settings.
559 `GIT_COMMITTER_EMAIL`::
560 The email address used in the author identity when creating commit or
561 tag objects, or when writing reflogs. Overrides the `user.email` and
562 `committer.email` configuration settings.
564 `GIT_COMMITTER_DATE`::
565 The date used for the committer identity when creating commit or tag objects, or
566 when writing reflogs. See linkgit:git-commit[1] for valid formats.
569 The email address used in the author and committer identities if no other
570 relevant environment variable or configuration setting has been set.
575 Only valid setting is "--unified=??" or "-u??" to set the
576 number of context lines shown when a unified diff is created.
577 This takes precedence over any "-U" or "--unified" option
578 value passed on the Git diff command line.
580 `GIT_EXTERNAL_DIFF`::
581 When the environment variable `GIT_EXTERNAL_DIFF` is set, the
582 program named by it is called to generate diffs, and Git
583 does not use its builtin diff machinery.
584 For a path that is added, removed, or modified,
585 `GIT_EXTERNAL_DIFF` is called with 7 parameters:
587 path old-file old-hex old-mode new-file new-hex new-mode
591 <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
592 contents of <old|new>,
593 <old|new>-hex:: are the 40-hexdigit SHA-1 hashes,
594 <old|new>-mode:: are the octal representation of the file modes.
596 The file parameters can point at the user's working file
597 (e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file`
598 when a new file is added), or a temporary file (e.g. `old-file` in the
599 index). `GIT_EXTERNAL_DIFF` should not worry about unlinking the
600 temporary file --- it is removed when `GIT_EXTERNAL_DIFF` exits.
602 For a path that is unmerged, `GIT_EXTERNAL_DIFF` is called with 1
605 For each path `GIT_EXTERNAL_DIFF` is called, two environment variables,
606 `GIT_DIFF_PATH_COUNTER` and `GIT_DIFF_PATH_TOTAL` are set.
608 `GIT_DIFF_PATH_COUNTER`::
609 A 1-based counter incremented by one for every path.
611 `GIT_DIFF_PATH_TOTAL`::
612 The total number of paths.
616 `GIT_MERGE_VERBOSITY`::
617 A number controlling the amount of output shown by
618 the recursive merge strategy. Overrides merge.verbosity.
619 See linkgit:git-merge[1]
622 This environment variable overrides `$PAGER`. If it is set
623 to an empty string or to the value "cat", Git will not launch
624 a pager. See also the `core.pager` option in
625 linkgit:git-config[1].
627 `GIT_PROGRESS_DELAY`::
628 A number controlling how many seconds to delay before showing
629 optional progress indicators. Defaults to 2.
632 This environment variable overrides `$EDITOR` and `$VISUAL`.
633 It is used by several Git commands when, on interactive mode,
634 an editor is to be launched. See also linkgit:git-var[1]
635 and the `core.editor` option in linkgit:git-config[1].
637 `GIT_SEQUENCE_EDITOR`::
638 This environment variable overrides the configured Git editor
639 when editing the todo list of an interactive rebase. See also
640 linkgit:git-rebase[1] and the `sequence.editor` option in
641 linkgit:git-config[1].
645 If either of these environment variables is set then 'git fetch'
646 and 'git push' will use the specified command instead of 'ssh'
647 when they need to connect to a remote system.
648 The command-line parameters passed to the configured command are
649 determined by the ssh variant. See `ssh.variant` option in
650 linkgit:git-config[1] for details.
652 `$GIT_SSH_COMMAND` takes precedence over `$GIT_SSH`, and is interpreted
653 by the shell, which allows additional arguments to be included.
654 `$GIT_SSH` on the other hand must be just the path to a program
655 (which can be a wrapper shell script, if additional arguments are
658 Usually it is easier to configure any desired options through your
659 personal `.ssh/config` file. Please consult your ssh documentation
663 If this environment variable is set, it overrides Git's autodetection
664 whether `GIT_SSH`/`GIT_SSH_COMMAND`/`core.sshCommand` refer to OpenSSH,
665 plink or tortoiseplink. This variable overrides the config setting
666 `ssh.variant` that serves the same purpose.
669 If this environment variable is set, then Git commands which need to
670 acquire passwords or passphrases (e.g. for HTTP or IMAP authentication)
671 will call this program with a suitable prompt as command-line argument
672 and read the password from its STDOUT. See also the `core.askPass`
673 option in linkgit:git-config[1].
675 `GIT_TERMINAL_PROMPT`::
676 If this environment variable is set to `0`, git will not prompt
677 on the terminal (e.g., when asking for HTTP authentication).
679 `GIT_CONFIG_GLOBAL`::
680 `GIT_CONFIG_SYSTEM`::
681 Take the configuration from the given files instead from global or
682 system-level configuration files. If `GIT_CONFIG_SYSTEM` is set, the
683 system config file defined at build time (usually `/etc/gitconfig`)
684 will not be read. Likewise, if `GIT_CONFIG_GLOBAL` is set, neither
685 `$HOME/.gitconfig` nor `$XDG_CONFIG_HOME/git/config` will be read. Can
686 be set to `/dev/null` to skip reading configuration files of the
689 `GIT_CONFIG_NOSYSTEM`::
690 Whether to skip reading settings from the system-wide
691 `$(prefix)/etc/gitconfig` file. This environment variable can
692 be used along with `$HOME` and `$XDG_CONFIG_HOME` to create a
693 predictable environment for a picky script, or you can set it
694 temporarily to avoid using a buggy `/etc/gitconfig` file while
695 waiting for someone with sufficient permissions to fix it.
698 If this environment variable is set to "1", then commands such
699 as 'git blame' (in incremental mode), 'git rev-list', 'git log',
700 'git check-attr' and 'git check-ignore' will
701 force a flush of the output stream after each record have been
703 variable is set to "0", the output of these commands will be done
704 using completely buffered I/O. If this environment variable is
705 not set, Git will choose buffered or record-oriented flushing
706 based on whether stdout appears to be redirected to a file or not.
709 Enables general trace messages, e.g. alias expansion, built-in
710 command execution and external command execution.
712 If this variable is set to "1", "2" or "true" (comparison
713 is case insensitive), trace messages will be printed to
716 If the variable is set to an integer value greater than 2
717 and lower than 10 (strictly) then Git will interpret this
718 value as an open file descriptor and will try to write the
719 trace messages into this file descriptor.
721 Alternatively, if the variable is set to an absolute path
722 (starting with a '/' character), Git will interpret this
723 as a file path and will try to append the trace messages
726 Unsetting the variable, or setting it to empty, "0" or
727 "false" (case insensitive) disables trace messages.
729 `GIT_TRACE_FSMONITOR`::
730 Enables trace messages for the filesystem monitor extension.
731 See `GIT_TRACE` for available trace output options.
733 `GIT_TRACE_PACK_ACCESS`::
734 Enables trace messages for all accesses to any packs. For each
735 access, the pack file name and an offset in the pack is
736 recorded. This may be helpful for troubleshooting some
737 pack-related performance problems.
738 See `GIT_TRACE` for available trace output options.
741 Enables trace messages for all packets coming in or out of a
742 given program. This can help with debugging object negotiation
743 or other protocol issues. Tracing is turned off at a packet
744 starting with "PACK" (but see `GIT_TRACE_PACKFILE` below).
745 See `GIT_TRACE` for available trace output options.
747 `GIT_TRACE_PACKFILE`::
748 Enables tracing of packfiles sent or received by a
749 given program. Unlike other trace output, this trace is
750 verbatim: no headers, and no quoting of binary data. You almost
751 certainly want to direct into a file (e.g.,
752 `GIT_TRACE_PACKFILE=/tmp/my.pack`) rather than displaying it on
753 the terminal or mixing it with other trace output.
755 Note that this is currently only implemented for the client side
756 of clones and fetches.
758 `GIT_TRACE_PERFORMANCE`::
759 Enables performance related trace messages, e.g. total execution
760 time of each Git command.
761 See `GIT_TRACE` for available trace output options.
764 Enables trace messages for operations on the ref database.
765 See `GIT_TRACE` for available trace output options.
768 Enables trace messages printing the .git, working tree and current
769 working directory after Git has completed its setup phase.
770 See `GIT_TRACE` for available trace output options.
772 `GIT_TRACE_SHALLOW`::
773 Enables trace messages that can help debugging fetching /
774 cloning of shallow repositories.
775 See `GIT_TRACE` for available trace output options.
778 Enables a curl full trace dump of all incoming and outgoing data,
779 including descriptive information, of the git transport protocol.
780 This is similar to doing curl `--trace-ascii` on the command line.
781 See `GIT_TRACE` for available trace output options.
783 `GIT_TRACE_CURL_NO_DATA`::
784 When a curl trace is enabled (see `GIT_TRACE_CURL` above), do not dump
785 data (that is, only dump info lines and headers).
788 Enables more detailed trace messages from the "trace2" library.
789 Output from `GIT_TRACE2` is a simple text-based format for human
792 If this variable is set to "1", "2" or "true" (comparison
793 is case insensitive), trace messages will be printed to
796 If the variable is set to an integer value greater than 2
797 and lower than 10 (strictly) then Git will interpret this
798 value as an open file descriptor and will try to write the
799 trace messages into this file descriptor.
801 Alternatively, if the variable is set to an absolute path
802 (starting with a '/' character), Git will interpret this
803 as a file path and will try to append the trace messages
804 to it. If the path already exists and is a directory, the
805 trace messages will be written to files (one per process)
806 in that directory, named according to the last component
807 of the SID and an optional counter (to avoid filename
810 In addition, if the variable is set to
811 `af_unix:[<socket_type>:]<absolute-pathname>`, Git will try
812 to open the path as a Unix Domain Socket. The socket type
813 can be either `stream` or `dgram`.
815 Unsetting the variable, or setting it to empty, "0" or
816 "false" (case insensitive) disables trace messages.
818 See link:technical/api-trace2.html[Trace2 documentation]
823 This setting writes a JSON-based format that is suited for machine
825 See `GIT_TRACE2` for available trace output options and
826 link:technical/api-trace2.html[Trace2 documentation] for full details.
829 In addition to the text-based messages available in `GIT_TRACE2`, this
830 setting writes a column-based format for understanding nesting
832 See `GIT_TRACE2` for available trace output options and
833 link:technical/api-trace2.html[Trace2 documentation] for full details.
836 By default, when tracing is activated, Git redacts the values of
837 cookies, the "Authorization:" header, the "Proxy-Authorization:"
838 header and packfile URIs. Set this variable to `0` to prevent this
841 `GIT_LITERAL_PATHSPECS`::
842 Setting this variable to `1` will cause Git to treat all
843 pathspecs literally, rather than as glob patterns. For example,
844 running `GIT_LITERAL_PATHSPECS=1 git log -- '*.c'` will search
845 for commits that touch the path `*.c`, not any paths that the
846 glob `*.c` matches. You might want this if you are feeding
847 literal paths to Git (e.g., paths previously given to you by
848 `git ls-tree`, `--raw` diff output, etc).
850 `GIT_GLOB_PATHSPECS`::
851 Setting this variable to `1` will cause Git to treat all
852 pathspecs as glob patterns (aka "glob" magic).
854 `GIT_NOGLOB_PATHSPECS`::
855 Setting this variable to `1` will cause Git to treat all
856 pathspecs as literal (aka "literal" magic).
858 `GIT_ICASE_PATHSPECS`::
859 Setting this variable to `1` will cause Git to treat all
860 pathspecs as case-insensitive.
862 `GIT_REFLOG_ACTION`::
863 When a ref is updated, reflog entries are created to keep
864 track of the reason why the ref was updated (which is
865 typically the name of the high-level command that updated
866 the ref), in addition to the old and new values of the ref.
867 A scripted Porcelain command can use set_reflog_action
868 helper function in `git-sh-setup` to set its name to this
869 variable when it is invoked as the top level command by the
870 end user, to be recorded in the body of the reflog.
873 If set to `0`, ignore broken or badly named refs when iterating
874 over lists of refs. Normally Git will try to include any such
875 refs, which may cause some operations to fail. This is usually
876 preferable, as potentially destructive operations (e.g.,
877 linkgit:git-prune[1]) are better off aborting rather than
878 ignoring broken refs (and thus considering the history they
879 point to as not worth saving). The default value is `1` (i.e.,
880 be paranoid about detecting and aborting all operations). You
881 should not normally need to set this to `0`, but it may be
882 useful when trying to salvage data from a corrupted repository.
884 `GIT_ALLOW_PROTOCOL`::
885 If set to a colon-separated list of protocols, behave as if
886 `protocol.allow` is set to `never`, and each of the listed
887 protocols has `protocol.<name>.allow` set to `always`
888 (overriding any existing configuration). In other words, any
889 protocol not mentioned will be disallowed (i.e., this is a
890 whitelist, not a blacklist). See the description of
891 `protocol.allow` in linkgit:git-config[1] for more details.
893 `GIT_PROTOCOL_FROM_USER`::
894 Set to 0 to prevent protocols used by fetch/push/clone which are
895 configured to the `user` state. This is useful to restrict recursive
896 submodule initialization from an untrusted repository or for programs
897 which feed potentially-untrusted URLS to git commands. See
898 linkgit:git-config[1] for more details.
901 For internal use only. Used in handshaking the wire protocol.
902 Contains a colon ':' separated list of keys with optional values
903 'key[=value]'. Presence of unknown keys and values must be
906 Note that servers may need to be configured to allow this variable to
907 pass over some transports. It will be propagated automatically when
908 accessing local repositories (i.e., `file://` or a filesystem path), as
909 well as over the `git://` protocol. For git-over-http, it should work
910 automatically in most configurations, but see the discussion in
911 linkgit:git-http-backend[1]. For git-over-ssh, the ssh server may need
912 to be configured to allow clients to pass this variable (e.g., by using
913 `AcceptEnv GIT_PROTOCOL` with OpenSSH).
915 This configuration is optional. If the variable is not propagated, then
916 clients will fall back to the original "v0" protocol (but may miss out
917 on some performance improvements or features). This variable currently
918 only affects clones and fetches; it is not yet used for pushes (but may
921 `GIT_OPTIONAL_LOCKS`::
922 If set to `0`, Git will complete any requested operation without
923 performing any optional sub-operations that require taking a lock.
924 For example, this will prevent `git status` from refreshing the
925 index as a side effect. This is useful for processes running in
926 the background which do not want to cause lock contention with
927 other operations on the repository. Defaults to `1`.
929 `GIT_REDIRECT_STDIN`::
930 `GIT_REDIRECT_STDOUT`::
931 `GIT_REDIRECT_STDERR`::
932 Windows-only: allow redirecting the standard input/output/error
933 handles to paths specified by the environment variables. This is
934 particularly useful in multi-threaded applications where the
935 canonical way to pass standard handles via `CreateProcess()` is
936 not an option because it would require the handles to be marked
937 inheritable (and consequently *every* spawned process would
938 inherit them, possibly blocking regular Git operations). The
939 primary intended use case is to use named pipes for communication
940 (e.g. `\\.\pipe\my-git-stdin-123`).
942 Two special values are supported: `off` will simply close the
943 corresponding standard handle, and if `GIT_REDIRECT_STDERR` is
944 `2>&1`, standard error will be redirected to the same handle as
947 `GIT_PRINT_SHA1_ELLIPSIS` (deprecated)::
948 If set to `yes`, print an ellipsis following an
949 (abbreviated) SHA-1 value. This affects indications of
950 detached HEADs (linkgit:git-checkout[1]) and the raw
951 diff output (linkgit:git-diff[1]). Printing an
952 ellipsis in the cases mentioned is no longer considered
953 adequate and support for it is likely to be removed in the
954 foreseeable future (along with the variable).
956 Discussion[[Discussion]]
957 ------------------------
959 More detail on the following is available from the
960 link:user-manual.html#git-concepts[Git concepts chapter of the
961 user-manual] and linkgit:gitcore-tutorial[7].
963 A Git project normally consists of a working directory with a ".git"
964 subdirectory at the top level. The .git directory contains, among other
965 things, a compressed object database representing the complete history
966 of the project, an "index" file which links that history to the current
967 contents of the working tree, and named pointers into that history such
968 as tags and branch heads.
970 The object database contains objects of three main types: blobs, which
971 hold file data; trees, which point to blobs and other trees to build up
972 directory hierarchies; and commits, which each reference a single tree
973 and some number of parent commits.
975 The commit, equivalent to what other systems call a "changeset" or
976 "version", represents a step in the project's history, and each parent
977 represents an immediately preceding step. Commits with more than one
978 parent represent merges of independent lines of development.
980 All objects are named by the SHA-1 hash of their contents, normally
981 written as a string of 40 hex digits. Such names are globally unique.
982 The entire history leading up to a commit can be vouched for by signing
983 just that commit. A fourth object type, the tag, is provided for this
986 When first created, objects are stored in individual files, but for
987 efficiency may later be compressed together into "pack files".
989 Named pointers called refs mark interesting points in history. A ref
990 may contain the SHA-1 name of an object or the name of another ref. Refs
991 with names beginning `ref/head/` contain the SHA-1 name of the most
992 recent commit (or "head") of a branch under development. SHA-1 names of
993 tags of interest are stored under `ref/tags/`. A special ref named
994 `HEAD` contains the name of the currently checked-out branch.
996 The index file is initialized with a list of all paths and, for each
997 path, a blob object and a set of attributes. The blob object represents
998 the contents of the file as of the head of the current branch. The
999 attributes (last modified time, size, etc.) are taken from the
1000 corresponding file in the working tree. Subsequent changes to the
1001 working tree can be found by comparing these attributes. The index may
1002 be updated with new content, and new commits may be created from the
1003 content stored in the index.
1005 The index is also capable of storing multiple entries (called "stages")
1006 for a given pathname. These stages are used to hold the various
1007 unmerged version of a file when a merge is in progress.
1009 FURTHER DOCUMENTATION
1010 ---------------------
1012 See the references in the "description" section to get started
1013 using Git. The following is probably more detail than necessary
1014 for a first-time user.
1016 The link:user-manual.html#git-concepts[Git concepts chapter of the
1017 user-manual] and linkgit:gitcore-tutorial[7] both provide
1018 introductions to the underlying Git architecture.
1020 See linkgit:gitworkflows[7] for an overview of recommended workflows.
1022 See also the link:howto-index.html[howto] documents for some useful
1025 The internals are documented in the
1026 link:technical/api-index.html[Git API documentation].
1028 Users migrating from CVS may also want to
1029 read linkgit:gitcvs-migration[7].
1034 Git was started by Linus Torvalds, and is currently maintained by Junio
1035 C Hamano. Numerous contributions have come from the Git mailing list
1036 <git@vger.kernel.org>. http://www.openhub.net/p/git/contributors/summary
1037 gives you a more complete list of contributors.
1039 If you have a clone of git.git itself, the
1040 output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you
1041 the authors for specific parts of the project.
1046 Report bugs to the Git mailing list <git@vger.kernel.org> where the
1047 development and maintenance is primarily done. You do not have to be
1048 subscribed to the list to send a message there. See the list archive
1049 at https://lore.kernel.org/git for previous bug reports and other
1052 Issues which are security relevant should be disclosed privately to
1053 the Git Security mailing list <git-security@googlegroups.com>.
1057 linkgit:gittutorial[7], linkgit:gittutorial-2[7],
1058 linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
1059 linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
1060 linkgit:gitcli[7], link:user-manual.html[The Git User's Manual],
1061 linkgit:gitworkflows[7]
1065 Part of the linkgit:git[1] suite