1GIT(1) Git Manual GIT(1)
2
6 git - the stupid content tracker
7
9 git [--version] [--help] [-C <path>] [-c <name>=<value>]
10 [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
11 [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
12 [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
13 [--super-prefix=<path>] [--config-env <name>=<envvar>]
14 <command> [<args>]
15
17 Git is a fast, scalable, distributed revision control system with an
18 unusually rich command set that provides both high-level operations and
19 full access to internals.
20 See gittutorial(7) to get started, then see giteveryday(7) for a useful
22 minimum set of commands. The Git User’s Manual[1] has a more in-depth
23 introduction.
24 After you mastered the basic concepts, you can come back to this page
26 to learn what commands Git offers. You can learn more about individual
27 Git commands with "git help command". gitcli(7) manual page gives you
28 an overview of the command-line command syntax.
29 A formatted and hyperlinked copy of the latest Git documentation can be
31 viewed at https://git.github.io/htmldocs/git.html or
32 https://git-scm.com/docs.
33
35 --version
36 Prints the Git suite version that the git program came from.
37 --help
39 Prints the synopsis and a list of the most commonly used commands.
40 If the option --all or -a is given then all available commands are
41 printed. If a Git command is named this option will bring up the
42 manual page for that command.
43 Other options are available to control how the manual page is
45 displayed. See git-help(1) for more information, because git --help
46 ... is converted internally into git help ....
47 -C <path>
49 Run as if git was started in <path> instead of the current working
50 directory. When multiple -C options are given, each subsequent
51 non-absolute -C <path> is interpreted relative to the preceding -C
52 <path>. If <path> is present but empty, e.g. -C "", then the
53 current working directory is left unchanged.
54 This option affects options that expect path name like --git-dir
56 and --work-tree in that their interpretations of the path names
57 would be made relative to the working directory caused by the -C
58 option. For example the following invocations are equivalent:
59 git --git-dir=a.git --work-tree=b -C c status
61 git --git-dir=c/a.git --work-tree=c/b status
62 -c <name>=<value>
64 Pass a configuration parameter to the command. The value given will
65 override values from configuration files. The <name> is expected in
66 the same format as listed by git config (subkeys separated by
67 dots).
68 Note that omitting the = in git -c foo.bar ... is allowed and sets
70 foo.bar to the boolean true value (just like [foo]bar would in a
71 config file). Including the equals but with an empty value (like
72 git -c foo.bar= ...) sets foo.bar to the empty string which git
73 config --type=bool will convert to false.
74 --config-env=<name>=<envvar>
76 Like -c <name>=<value>, give configuration variable <name> a value,
77 where <envvar> is the name of an environment variable from which to
78 retrieve the value. Unlike -c there is no shortcut for directly
79 setting the value to an empty string, instead the environment
80 variable itself must be set to the empty string. It is an error if
81 the <envvar> does not exist in the environment. <envvar> may not
82 contain an equals sign to avoid ambiguity with <name> containing
83 one.
84 This is useful for cases where you want to pass transitory
86 configuration options to git, but are doing so on OS’s where other
87 processes might be able to read your cmdline (e.g.
88 /proc/self/cmdline), but not your environ (e.g.
89 /proc/self/environ). That behavior is the default on Linux, but may
90 not be on your system.
91 Note that this might add security for variables such as
93 http.extraHeader where the sensitive information is part of the
94 value, but not e.g. url.<base>.insteadOf where the sensitive
95 information can be part of the key.
96 --exec-path[=<path>]
98 Path to wherever your core Git programs are installed. This can
99 also be controlled by setting the GIT_EXEC_PATH environment
100 variable. If no path is given, git will print the current setting
101 and then exit.
102 --html-path
104 Print the path, without trailing slash, where Git’s HTML
105 documentation is installed and exit.
106 --man-path
108 Print the manpath (see man(1)) for the man pages for this version
109 of Git and exit.
110 --info-path
112 Print the path where the Info files documenting this version of Git
113 are installed and exit.
114 -p, --paginate
116 Pipe all output into less (or if set, $PAGER) if standard output is
117 a terminal. This overrides the pager.<cmd> configuration options
118 (see the "Configuration Mechanism" section below).
119 -P, --no-pager
121 Do not pipe Git output into a pager.
122 --git-dir=<path>
124 Set the path to the repository (".git" directory). This can also be
125 controlled by setting the GIT_DIR environment variable. It can be
126 an absolute path or relative path to current working directory.
127 Specifying the location of the ".git" directory using this option
129 (or GIT_DIR environment variable) turns off the repository
130 discovery that tries to find a directory with ".git" subdirectory
131 (which is how the repository and the top-level of the working tree
132 are discovered), and tells Git that you are at the top level of the
133 working tree. If you are not at the top-level directory of the
134 working tree, you should tell Git where the top-level of the
135 working tree is, with the --work-tree=<path> option (or
136 GIT_WORK_TREE environment variable)
137 If you just want to run git as if it was started in <path> then use
139 git -C <path>.
140 --work-tree=<path>
142 Set the path to the working tree. It can be an absolute path or a
143 path relative to the current working directory. This can also be
144 controlled by setting the GIT_WORK_TREE environment variable and
145 the core.worktree configuration variable (see core.worktree in git-
146 config(1) for a more detailed discussion).
147 --namespace=<path>
149 Set the Git namespace. See gitnamespaces(7) for more details.
150 Equivalent to setting the GIT_NAMESPACE environment variable.
151 --super-prefix=<path>
153 Currently for internal use only. Set a prefix which gives a path
154 from above a repository down to its root. One use is to give
155 submodules context about the superproject that invoked it.
156 --bare
158 Treat the repository as a bare repository. If GIT_DIR environment
159 is not set, it is set to the current working directory.
160 --no-replace-objects
162 Do not use replacement refs to replace Git objects. See git-
163 replace(1) for more information.
164 --literal-pathspecs
166 Treat pathspecs literally (i.e. no globbing, no pathspec magic).
167 This is equivalent to setting the GIT_LITERAL_PATHSPECS environment
168 variable to 1.
169 --glob-pathspecs
171 Add "glob" magic to all pathspec. This is equivalent to setting the
172 GIT_GLOB_PATHSPECS environment variable to 1. Disabling globbing on
173 individual pathspecs can be done using pathspec magic ":(literal)"
174 --noglob-pathspecs
176 Add "literal" magic to all pathspec. This is equivalent to setting
177 the GIT_NOGLOB_PATHSPECS environment variable to 1. Enabling
178 globbing on individual pathspecs can be done using pathspec magic
179 ":(glob)"
180 --icase-pathspecs
182 Add "icase" magic to all pathspec. This is equivalent to setting
183 the GIT_ICASE_PATHSPECS environment variable to 1.
184 --no-optional-locks
186 Do not perform optional operations that require locks. This is
187 equivalent to setting the GIT_OPTIONAL_LOCKS to 0.
188 --list-cmds=group[,group...]
190 List commands by group. This is an internal/experimental option and
191 may change or be removed in the future. Supported groups are:
192 builtins, parseopt (builtin commands that use parse-options), main
193 (all commands in libexec directory), others (all other commands in
194 $PATH that have git- prefix), list-<category> (see categories in
195 command-list.txt), nohelpers (exclude helper commands), alias and
196 config (retrieve command list from config variable
197 completion.commands)
198
200 We divide Git into high level ("porcelain") commands and low level
201 ("plumbing") commands.
202
204 We separate the porcelain commands into the main commands and some
205 ancillary user utilities.
206 Main porcelain commands
208 Unresolved directive in git.txt - include::cmds-mainporcelain.txt[]
209 Ancillary Commands
211 Manipulators:
212 Unresolved directive in git.txt -
214 include::cmds-ancillarymanipulators.txt[]
215 Interrogators:
217 Unresolved directive in git.txt -
219 include::cmds-ancillaryinterrogators.txt[]
220 Interacting with Others
222 These commands are to interact with foreign SCM and with other people
223 via patch over e-mail.
224 Unresolved directive in git.txt -
226 include::cmds-foreignscminterface.txt[]
227 Reset, restore and revert
229 There are three commands with similar names: git reset, git restore and
230 git revert.
231 • git-revert(1) is about making a new commit that reverts the changes
233 made by other commits.
234 • git-restore(1) is about restoring files in the working tree from
236 either the index or another commit. This command does not update
237 your branch. The command can also be used to restore files in the
238 index from another commit.
239 • git-reset(1) is about updating your branch, moving the tip in order
241 to add or remove commits from the branch. This operation changes
242 the commit history.
243 git reset can also be used to restore the index, overlapping with
245 git restore.
246
248 Although Git includes its own porcelain layer, its low-level commands
249 are sufficient to support development of alternative porcelains.
250 Developers of such porcelains might start by reading about git-update-
251 index(1) and git-read-tree(1).
252 The interface (input, output, set of options and the semantics) to
254 these low-level commands are meant to be a lot more stable than
255 Porcelain level commands, because these commands are primarily for
256 scripted use. The interface to Porcelain commands on the other hand are
257 subject to change in order to improve the end user experience.
258 The following description divides the low-level commands into commands
260 that manipulate objects (in the repository, index, and working tree),
261 commands that interrogate and compare objects, and commands that move
262 objects and references between repositories.
263 Manipulation commands
265 Unresolved directive in git.txt -
266 include::cmds-plumbingmanipulators.txt[]
267 Interrogation commands
269 Unresolved directive in git.txt -
270 include::cmds-plumbinginterrogators.txt[]
271 In general, the interrogate commands do not touch the files in the
273 working tree.
274 Syncing repositories
276 Unresolved directive in git.txt -
277 include::cmds-synchingrepositories.txt[]
278 The following are helper commands used by the above; end users
280 typically do not use them directly.
281 Unresolved directive in git.txt - include::cmds-synchelpers.txt[]
283 Internal helper commands
285 These are internal helper commands used by other commands; end users
286 typically do not use them directly.
287 Unresolved directive in git.txt - include::cmds-purehelpers.txt[]
289
291 The following documentation pages are guides about Git concepts.
292 Unresolved directive in git.txt - include::cmds-guide.txt[]
294
296 Git uses a simple text format to store customizations that are per
297 repository and are per user. Such a configuration file may look like
298 this:
299 #
301 # A '#' or ';' character indicates a comment.
302 #
303 ; core variables
305 [core]
306 ; Don't trust file modes
307 filemode = false
308 ; user identity
310 [user]
311 name = "Junio C Hamano"
312 email = "gitster@pobox.com"
313 Various commands read from the configuration file and adjust their
315 operation accordingly. See git-config(1) for a list and more details
316 about the configuration mechanism.
317
319 <object>
320 Indicates the object name for any type of object.
321 <blob>
323 Indicates a blob object name.
324 <tree>
326 Indicates a tree object name.
327 <commit>
329 Indicates a commit object name.
330 <tree-ish>
332 Indicates a tree, commit or tag object name. A command that takes a
333 <tree-ish> argument ultimately wants to operate on a <tree> object
334 but automatically dereferences <commit> and <tag> objects that
335 point at a <tree>.
336 <commit-ish>
338 Indicates a commit or tag object name. A command that takes a
339 <commit-ish> argument ultimately wants to operate on a <commit>
340 object but automatically dereferences <tag> objects that point at a
341 <commit>.
342 <type>
344 Indicates that an object type is required. Currently one of: blob,
345 tree, commit, or tag.
346 <file>
348 Indicates a filename - almost always relative to the root of the
349 tree structure GIT_INDEX_FILE describes.
350
352 Any Git command accepting any <object> can also use the following
353 symbolic notation:
354 HEAD
356 indicates the head of the current branch.
357 <tag>
359 a valid tag name (i.e. a refs/tags/<tag> reference).
360 <head>
362 a valid head name (i.e. a refs/heads/<head> reference).
363 For a more complete list of ways to spell object names, see "SPECIFYING
365 REVISIONS" section in gitrevisions(7).
366
368 Please see the gitrepository-layout(5) document.
369 Read githooks(5) for more details about each hook.
371 Higher level SCMs may provide and manage additional information in the
373 $GIT_DIR.
374
376 Please see gitglossary(7).
377
379 Various Git commands use the following environment variables:
380 The Git Repository
382 These environment variables apply to all core Git commands. Nb: it is
383 worth noting that they may be used/overridden by SCMS sitting above Git
384 so take care if using a foreign front-end.
385 GIT_INDEX_FILE
387 This environment allows the specification of an alternate index
388 file. If not specified, the default of $GIT_DIR/index is used.
389 GIT_INDEX_VERSION
391 This environment variable allows the specification of an index
392 version for new repositories. It won’t affect existing index files.
393 By default index file version 2 or 3 is used. See git-update-
394 index(1) for more information.
395 GIT_OBJECT_DIRECTORY
397 If the object storage directory is specified via this environment
398 variable then the sha1 directories are created underneath -
399 otherwise the default $GIT_DIR/objects directory is used.
400 GIT_ALTERNATE_OBJECT_DIRECTORIES
402 Due to the immutable nature of Git objects, old objects can be
403 archived into shared, read-only directories. This variable
404 specifies a ":" separated (on Windows ";" separated) list of Git
405 object directories which can be used to search for Git objects. New
406 objects will not be written to these directories.
407 Entries that begin with " (double-quote) will be interpreted as
409 C-style quoted paths, removing leading and trailing double-quotes
410 and respecting backslash escapes. E.g., the value
411 "path-with-\"-and-:-in-it":vanilla-path has two paths:
412 path-with-"-and-:-in-it and vanilla-path.
413 GIT_DIR
415 If the GIT_DIR environment variable is set then it specifies a path
416 to use instead of the default .git for the base of the repository.
417 The --git-dir command-line option also sets this value.
418 GIT_WORK_TREE
420 Set the path to the root of the working tree. This can also be
421 controlled by the --work-tree command-line option and the
422 core.worktree configuration variable.
423 GIT_NAMESPACE
425 Set the Git namespace; see gitnamespaces(7) for details. The
426 --namespace command-line option also sets this value.
427 GIT_CEILING_DIRECTORIES
429 This should be a colon-separated list of absolute paths. If set, it
430 is a list of directories that Git should not chdir up into while
431 looking for a repository directory (useful for excluding
432 slow-loading network directories). It will not exclude the current
433 working directory or a GIT_DIR set on the command line or in the
434 environment. Normally, Git has to read the entries in this list and
435 resolve any symlink that might be present in order to compare them
436 with the current directory. However, if even this access is slow,
437 you can add an empty entry to the list to tell Git that the
438 subsequent entries are not symlinks and needn’t be resolved; e.g.,
439 GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.
440 GIT_DISCOVERY_ACROSS_FILESYSTEM
442 When run in a directory that does not have ".git" repository
443 directory, Git tries to find such a directory in the parent
444 directories to find the top of the working tree, but by default it
445 does not cross filesystem boundaries. This environment variable can
446 be set to true to tell Git not to stop at filesystem boundaries.
447 Like GIT_CEILING_DIRECTORIES, this will not affect an explicit
448 repository directory set via GIT_DIR or on the command line.
449 GIT_COMMON_DIR
451 If this variable is set to a path, non-worktree files that are
452 normally in $GIT_DIR will be taken from this path instead.
453 Worktree-specific files such as HEAD or index are taken from
454 $GIT_DIR. See gitrepository-layout(5) and git-worktree(1) for
455 details. This variable has lower precedence than other path
456 variables such as GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY...
457 GIT_DEFAULT_HASH
459 If this variable is set, the default hash algorithm for new
460 repositories will be set to this value. This value is currently
461 ignored when cloning; the setting of the remote repository is used
462 instead. The default is "sha1". THIS VARIABLE IS EXPERIMENTAL! See
463 --object-format in git-init(1).
464 Git Commits
466 GIT_AUTHOR_NAME
467 The human-readable name used in the author identity when creating
468 commit or tag objects, or when writing reflogs. Overrides the
469 user.name and author.name configuration settings.
470 GIT_AUTHOR_EMAIL
472 The email address used in the author identity when creating commit
473 or tag objects, or when writing reflogs. Overrides the user.email
474 and author.email configuration settings.
475 GIT_AUTHOR_DATE
477 The date used for the author identity when creating commit or tag
478 objects, or when writing reflogs. See git-commit(1) for valid
479 formats.
480 GIT_COMMITTER_NAME
482 The human-readable name used in the committer identity when
483 creating commit or tag objects, or when writing reflogs. Overrides
484 the user.name and committer.name configuration settings.
485 GIT_COMMITTER_EMAIL
487 The email address used in the author identity when creating commit
488 or tag objects, or when writing reflogs. Overrides the user.email
489 and committer.email configuration settings.
490 GIT_COMMITTER_DATE
492 The date used for the committer identity when creating commit or
493 tag objects, or when writing reflogs. See git-commit(1) for valid
494 formats.
495 EMAIL
497 The email address used in the author and committer identities if no
498 other relevant environment variable or configuration setting has
499 been set.
500 Git Diffs
502 GIT_DIFF_OPTS
503 Only valid setting is "--unified=??" or "-u??" to set the number of
504 context lines shown when a unified diff is created. This takes
505 precedence over any "-U" or "--unified" option value passed on the
506 Git diff command line.
507 GIT_EXTERNAL_DIFF
509 When the environment variable GIT_EXTERNAL_DIFF is set, the program
510 named by it is called to generate diffs, and Git does not use its
511 builtin diff machinery. For a path that is added, removed, or
512 modified, GIT_EXTERNAL_DIFF is called with 7 parameters:
513 path old-file old-hex old-mode new-file new-hex new-mode
515 where:
517 <old|new>-file
519 are files GIT_EXTERNAL_DIFF can use to read the contents of
520 <old|new>,
521 <old|new>-hex
523 are the 40-hexdigit SHA-1 hashes,
524 <old|new>-mode
526 are the octal representation of the file modes.
527 The file parameters can point at the user’s working file (e.g.
529 new-file in "git-diff-files"), /dev/null (e.g. old-file when a new
530 file is added), or a temporary file (e.g. old-file in the index).
531 GIT_EXTERNAL_DIFF should not worry about unlinking the temporary
532 file --- it is removed when GIT_EXTERNAL_DIFF exits.
533 For a path that is unmerged, GIT_EXTERNAL_DIFF is called with 1
535 parameter, <path>.
536 For each path GIT_EXTERNAL_DIFF is called, two environment
538 variables, GIT_DIFF_PATH_COUNTER and GIT_DIFF_PATH_TOTAL are set.
539 GIT_DIFF_PATH_COUNTER
541 A 1-based counter incremented by one for every path.
542 GIT_DIFF_PATH_TOTAL
544 The total number of paths.
545 other
547 GIT_MERGE_VERBOSITY
548 A number controlling the amount of output shown by the recursive
549 merge strategy. Overrides merge.verbosity. See git-merge(1)
550 GIT_PAGER
552 This environment variable overrides $PAGER. If it is set to an
553 empty string or to the value "cat", Git will not launch a pager.
554 See also the core.pager option in git-config(1).
555 GIT_PROGRESS_DELAY
557 A number controlling how many seconds to delay before showing
558 optional progress indicators. Defaults to 2.
559 GIT_EDITOR
561 This environment variable overrides $EDITOR and $VISUAL. It is used
562 by several Git commands when, on interactive mode, an editor is to
563 be launched. See also git-var(1) and the core.editor option in git-
564 config(1).
565 GIT_SEQUENCE_EDITOR
567 This environment variable overrides the configured Git editor when
568 editing the todo list of an interactive rebase. See also git-
569 rebase(1) and the sequence.editor option in git-config(1).
570 GIT_SSH, GIT_SSH_COMMAND
572 If either of these environment variables is set then git fetch and
573 git push will use the specified command instead of ssh when they
574 need to connect to a remote system. The command-line parameters
575 passed to the configured command are determined by the ssh variant.
576 See ssh.variant option in git-config(1) for details.
577 $GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is interpreted
579 by the shell, which allows additional arguments to be included.
580 $GIT_SSH on the other hand must be just the path to a program
581 (which can be a wrapper shell script, if additional arguments are
582 needed).
583 Usually it is easier to configure any desired options through your
585 personal .ssh/config file. Please consult your ssh documentation
586 for further details.
587 GIT_SSH_VARIANT
589 If this environment variable is set, it overrides Git’s
590 autodetection whether GIT_SSH/GIT_SSH_COMMAND/core.sshCommand refer
591 to OpenSSH, plink or tortoiseplink. This variable overrides the
592 config setting ssh.variant that serves the same purpose.
593 GIT_ASKPASS
595 If this environment variable is set, then Git commands which need
596 to acquire passwords or passphrases (e.g. for HTTP or IMAP
597 authentication) will call this program with a suitable prompt as
598 command-line argument and read the password from its STDOUT. See
599 also the core.askPass option in git-config(1).
600 GIT_TERMINAL_PROMPT
602 If this environment variable is set to 0, git will not prompt on
603 the terminal (e.g., when asking for HTTP authentication).
604 GIT_CONFIG_NOSYSTEM
606 Whether to skip reading settings from the system-wide
607 $(prefix)/etc/gitconfig file. This environment variable can be used
608 along with $HOME and $XDG_CONFIG_HOME to create a predictable
609 environment for a picky script, or you can set it temporarily to
610 avoid using a buggy /etc/gitconfig file while waiting for someone
611 with sufficient permissions to fix it.
612 GIT_FLUSH
614 If this environment variable is set to "1", then commands such as
615 git blame (in incremental mode), git rev-list, git log, git
616 check-attr and git check-ignore will force a flush of the output
617 stream after each record have been flushed. If this variable is set
618 to "0", the output of these commands will be done using completely
619 buffered I/O. If this environment variable is not set, Git will
620 choose buffered or record-oriented flushing based on whether stdout
621 appears to be redirected to a file or not.
622 GIT_TRACE
624 Enables general trace messages, e.g. alias expansion, built-in
625 command execution and external command execution.
626 If this variable is set to "1", "2" or "true" (comparison is case
628 insensitive), trace messages will be printed to stderr.
629 If the variable is set to an integer value greater than 2 and lower
631 than 10 (strictly) then Git will interpret this value as an open
632 file descriptor and will try to write the trace messages into this
633 file descriptor.
634 Alternatively, if the variable is set to an absolute path (starting
636 with a / character), Git will interpret this as a file path and
637 will try to append the trace messages to it.
638 Unsetting the variable, or setting it to empty, "0" or "false"
640 (case insensitive) disables trace messages.
641 GIT_TRACE_FSMONITOR
643 Enables trace messages for the filesystem monitor extension. See
644 GIT_TRACE for available trace output options.
645 GIT_TRACE_PACK_ACCESS
647 Enables trace messages for all accesses to any packs. For each
648 access, the pack file name and an offset in the pack is recorded.
649 This may be helpful for troubleshooting some pack-related
650 performance problems. See GIT_TRACE for available trace output
651 options.
652 GIT_TRACE_PACKET
654 Enables trace messages for all packets coming in or out of a given
655 program. This can help with debugging object negotiation or other
656 protocol issues. Tracing is turned off at a packet starting with
657 "PACK" (but see GIT_TRACE_PACKFILE below). See GIT_TRACE for
658 available trace output options.
659 GIT_TRACE_PACKFILE
661 Enables tracing of packfiles sent or received by a given program.
662 Unlike other trace output, this trace is verbatim: no headers, and
663 no quoting of binary data. You almost certainly want to direct into
664 a file (e.g., GIT_TRACE_PACKFILE=/tmp/my.pack) rather than
665 displaying it on the terminal or mixing it with other trace output.
666 Note that this is currently only implemented for the client side of
668 clones and fetches.
669 GIT_TRACE_PERFORMANCE
671 Enables performance related trace messages, e.g. total execution
672 time of each Git command. See GIT_TRACE for available trace output
673 options.
674 GIT_TRACE_REFS
676 Enables trace messages for operations on the ref database. See
677 GIT_TRACE for available trace output options.
678 GIT_TRACE_SETUP
680 Enables trace messages printing the .git, working tree and current
681 working directory after Git has completed its setup phase. See
682 GIT_TRACE for available trace output options.
683 GIT_TRACE_SHALLOW
685 Enables trace messages that can help debugging fetching / cloning
686 of shallow repositories. See GIT_TRACE for available trace output
687 options.
688 GIT_TRACE_CURL
690 Enables a curl full trace dump of all incoming and outgoing data,
691 including descriptive information, of the git transport protocol.
692 This is similar to doing curl --trace-ascii on the command line.
693 See GIT_TRACE for available trace output options.
694 GIT_TRACE_CURL_NO_DATA
696 When a curl trace is enabled (see GIT_TRACE_CURL above), do not
697 dump data (that is, only dump info lines and headers).
698 GIT_TRACE2
700 Enables more detailed trace messages from the "trace2" library.
701 Output from GIT_TRACE2 is a simple text-based format for human
702 readability.
703 If this variable is set to "1", "2" or "true" (comparison is case
705 insensitive), trace messages will be printed to stderr.
706 If the variable is set to an integer value greater than 2 and lower
708 than 10 (strictly) then Git will interpret this value as an open
709 file descriptor and will try to write the trace messages into this
710 file descriptor.
711 Alternatively, if the variable is set to an absolute path (starting
713 with a / character), Git will interpret this as a file path and
714 will try to append the trace messages to it. If the path already
715 exists and is a directory, the trace messages will be written to
716 files (one per process) in that directory, named according to the
717 last component of the SID and an optional counter (to avoid
718 filename collisions).
719 In addition, if the variable is set to
721 af_unix:[<socket_type>:]<absolute-pathname>, Git will try to open
722 the path as a Unix Domain Socket. The socket type can be either
723 stream or dgram.
724 Unsetting the variable, or setting it to empty, "0" or "false"
726 (case insensitive) disables trace messages.
727 See Trace2 documentation[2] for full details.
729 GIT_TRACE2_EVENT
731 This setting writes a JSON-based format that is suited for machine
732 interpretation. See GIT_TRACE2 for available trace output options
733 and Trace2 documentation[2] for full details.
734 GIT_TRACE2_PERF
736 In addition to the text-based messages available in GIT_TRACE2,
737 this setting writes a column-based format for understanding nesting
738 regions. See GIT_TRACE2 for available trace output options and
739 Trace2 documentation[2] for full details.
740 GIT_TRACE_REDACT
742 By default, when tracing is activated, Git redacts the values of
743 cookies, the "Authorization:" header, and the
744 "Proxy-Authorization:" header. Set this variable to 0 to prevent
745 this redaction.
746 GIT_LITERAL_PATHSPECS
748 Setting this variable to 1 will cause Git to treat all pathspecs
749 literally, rather than as glob patterns. For example, running
750 GIT_LITERAL_PATHSPECS=1 git log -- '*.c' will search for commits
751 that touch the path *.c, not any paths that the glob *.c matches.
752 You might want this if you are feeding literal paths to Git (e.g.,
753 paths previously given to you by git ls-tree, --raw diff output,
754 etc).
755 GIT_GLOB_PATHSPECS
757 Setting this variable to 1 will cause Git to treat all pathspecs as
758 glob patterns (aka "glob" magic).
759 GIT_NOGLOB_PATHSPECS
761 Setting this variable to 1 will cause Git to treat all pathspecs as
762 literal (aka "literal" magic).
763 GIT_ICASE_PATHSPECS
765 Setting this variable to 1 will cause Git to treat all pathspecs as
766 case-insensitive.
767 GIT_REFLOG_ACTION
769 When a ref is updated, reflog entries are created to keep track of
770 the reason why the ref was updated (which is typically the name of
771 the high-level command that updated the ref), in addition to the
772 old and new values of the ref. A scripted Porcelain command can use
773 set_reflog_action helper function in git-sh-setup to set its name
774 to this variable when it is invoked as the top level command by the
775 end user, to be recorded in the body of the reflog.
776 GIT_REF_PARANOIA
778 If set to 1, include broken or badly named refs when iterating over
779 lists of refs. In a normal, non-corrupted repository, this does
780 nothing. However, enabling it may help git to detect and abort some
781 operations in the presence of broken refs. Git sets this variable
782 automatically when performing destructive operations like git-
783 prune(1). You should not need to set it yourself unless you want to
784 be paranoid about making sure an operation has touched every ref
785 (e.g., because you are cloning a repository to make a backup).
786 GIT_ALLOW_PROTOCOL
788 If set to a colon-separated list of protocols, behave as if
789 protocol.allow is set to never, and each of the listed protocols
790 has protocol.<name>.allow set to always (overriding any existing
791 configuration). In other words, any protocol not mentioned will be
792 disallowed (i.e., this is a whitelist, not a blacklist). See the
793 description of protocol.allow in git-config(1) for more details.
794 GIT_PROTOCOL_FROM_USER
796 Set to 0 to prevent protocols used by fetch/push/clone which are
797 configured to the user state. This is useful to restrict recursive
798 submodule initialization from an untrusted repository or for
799 programs which feed potentially-untrusted URLS to git commands. See
800 git-config(1) for more details.
801 GIT_PROTOCOL
803 For internal use only. Used in handshaking the wire protocol.
804 Contains a colon : separated list of keys with optional values
805 key[=value]. Presence of unknown keys and values must be ignored.
806 GIT_OPTIONAL_LOCKS
808 If set to 0, Git will complete any requested operation without
809 performing any optional sub-operations that require taking a lock.
810 For example, this will prevent git status from refreshing the index
811 as a side effect. This is useful for processes running in the
812 background which do not want to cause lock contention with other
813 operations on the repository. Defaults to 1.
814 GIT_REDIRECT_STDIN, GIT_REDIRECT_STDOUT, GIT_REDIRECT_STDERR
816 Windows-only: allow redirecting the standard input/output/error
817 handles to paths specified by the environment variables. This is
818 particularly useful in multi-threaded applications where the
819 canonical way to pass standard handles via CreateProcess() is not
820 an option because it would require the handles to be marked
821 inheritable (and consequently every spawned process would inherit
822 them, possibly blocking regular Git operations). The primary
823 intended use case is to use named pipes for communication (e.g.
824 \\.\pipe\my-git-stdin-123).
825 Two special values are supported: off will simply close the
827 corresponding standard handle, and if GIT_REDIRECT_STDERR is 2>&1,
828 standard error will be redirected to the same handle as standard
829 output.
830 GIT_PRINT_SHA1_ELLIPSIS (deprecated)
832 If set to yes, print an ellipsis following an (abbreviated) SHA-1
833 value. This affects indications of detached HEADs (git-checkout(1))
834 and the raw diff output (git-diff(1)). Printing an ellipsis in the
835 cases mentioned is no longer considered adequate and support for it
836 is likely to be removed in the foreseeable future (along with the
837 variable).
838
840 More detail on the following is available from the Git concepts chapter
841 of the user-manual[3] and gitcore-tutorial(7).
842 A Git project normally consists of a working directory with a ".git"
844 subdirectory at the top level. The .git directory contains, among other
845 things, a compressed object database representing the complete history
846 of the project, an "index" file which links that history to the current
847 contents of the working tree, and named pointers into that history such
848 as tags and branch heads.
849 The object database contains objects of three main types: blobs, which
851 hold file data; trees, which point to blobs and other trees to build up
852 directory hierarchies; and commits, which each reference a single tree
853 and some number of parent commits.
854 The commit, equivalent to what other systems call a "changeset" or
856 "version", represents a step in the project’s history, and each parent
857 represents an immediately preceding step. Commits with more than one
858 parent represent merges of independent lines of development.
859 All objects are named by the SHA-1 hash of their contents, normally
861 written as a string of 40 hex digits. Such names are globally unique.
862 The entire history leading up to a commit can be vouched for by signing
863 just that commit. A fourth object type, the tag, is provided for this
864 purpose.
865 When first created, objects are stored in individual files, but for
867 efficiency may later be compressed together into "pack files".
868 Named pointers called refs mark interesting points in history. A ref
870 may contain the SHA-1 name of an object or the name of another ref.
871 Refs with names beginning ref/head/ contain the SHA-1 name of the most
872 recent commit (or "head") of a branch under development. SHA-1 names of
873 tags of interest are stored under ref/tags/. A special ref named HEAD
874 contains the name of the currently checked-out branch.
875 The index file is initialized with a list of all paths and, for each
877 path, a blob object and a set of attributes. The blob object represents
878 the contents of the file as of the head of the current branch. The
879 attributes (last modified time, size, etc.) are taken from the
880 corresponding file in the working tree. Subsequent changes to the
881 working tree can be found by comparing these attributes. The index may
882 be updated with new content, and new commits may be created from the
883 content stored in the index.
884 The index is also capable of storing multiple entries (called "stages")
886 for a given pathname. These stages are used to hold the various
887 unmerged version of a file when a merge is in progress.
888
890 See the references in the "description" section to get started using
891 Git. The following is probably more detail than necessary for a
892 first-time user.
893 The Git concepts chapter of the user-manual[3] and gitcore-tutorial(7)
895 both provide introductions to the underlying Git architecture.
896 See gitworkflows(7) for an overview of recommended workflows.
898 See also the howto[4] documents for some useful examples.
900 The internals are documented in the Git API documentation[5].
902 Users migrating from CVS may also want to read gitcvs-migration(7).
904
906 Git was started by Linus Torvalds, and is currently maintained by Junio
907 C Hamano. Numerous contributions have come from the Git mailing list
908 <git@vger.kernel.org[6]>.
909 http://www.openhub.net/p/git/contributors/summary gives you a more
910 complete list of contributors.
911 If you have a clone of git.git itself, the output of git-shortlog(1)
913 and git-blame(1) can show you the authors for specific parts of the
914 project.
915
917 Report bugs to the Git mailing list <git@vger.kernel.org[6]> where the
918 development and maintenance is primarily done. You do not have to be
919 subscribed to the list to send a message there. See the list archive at
920 https://lore.kernel.org/git for previous bug reports and other
921 discussions.
922 Issues which are security relevant should be disclosed privately to the
924 Git Security mailing list <git-security@googlegroups.com[7]>.
925
927 gittutorial(7), gittutorial-2(7), giteveryday(7), gitcvs-migration(7),
928 gitglossary(7), gitcore-tutorial(7), gitcli(7), The Git User’s
929 Manual[1], gitworkflows(7)
930
932 Part of the git(1) suite
933
935 1. Git User’s Manual
936 file:///usr/share/doc/git/user-manual.html
937 2. Trace2 documentation
939 file:///usr/share/doc/git/technical/api-trace2.html
940 3. Git concepts chapter of the user-manual
942 file:///usr/share/doc/git/user-manual.html#git-concepts
943 4. howto
945 file:///usr/share/doc/git/howto-index.html
946 5. Git API documentation
948 file:///usr/share/doc/git/technical/api-index.html
949 6. git@vger.kernel.org
951 mailto:git@vger.kernel.org
952 7. git-security@googlegroups.com
954 mailto:git-security@googlegroups.com
955Git 2.31.1 2021-03-26 GIT(1)