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