6 git - the stupid content tracker
12 'git' [--version] [--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>]
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.
43 Prints the Git suite version that the 'git' program came from.
46 Prints the synopsis and a list of the most commonly used
47 commands. If the option `--all` or `-a` is given then all
48 available commands are printed. If a Git command is named this
49 option will bring up the manual page for that command.
51 Other options are available to control how the manual page is
52 displayed. See linkgit:git-help[1] for more information,
53 because `git --help ...` is converted internally into `git
57 Run as if git was started in '<path>' instead of the current working
58 directory. When multiple `-C` options are given, each subsequent
59 non-absolute `-C <path>` is interpreted relative to the preceding `-C
62 This option affects options that expect path name like `--git-dir` and
63 `--work-tree` in that their interpretations of the path names would be
64 made relative to the working directory caused by the `-C` option. For
65 example the following invocations are equivalent:
67 git --git-dir=a.git --work-tree=b -C c status
68 git --git-dir=c/a.git --work-tree=c/b status
71 Pass a configuration parameter to the command. The value
72 given will override values from configuration files.
73 The <name> is expected in the same format as listed by
74 'git config' (subkeys separated by dots).
76 Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets
77 `foo.bar` to the boolean true value (just like `[foo]bar` would in a
78 config file). Including the equals but with an empty value (like `git -c
79 foo.bar= ...`) sets `foo.bar` to the empty string which `git config
80 --type=bool` will convert to `false`.
82 --exec-path[=<path>]::
83 Path to wherever your core Git programs are installed.
84 This can also be controlled by setting the GIT_EXEC_PATH
85 environment variable. If no path is given, 'git' will print
86 the current setting and then exit.
89 Print the path, without trailing slash, where Git's HTML
90 documentation is installed and exit.
93 Print the manpath (see `man(1)`) for the man pages for
94 this version of Git and exit.
97 Print the path where the Info files documenting this
98 version of Git are installed and exit.
102 Pipe all output into 'less' (or if set, $PAGER) if standard
103 output is a terminal. This overrides the `pager.<cmd>`
104 configuration options (see the "Configuration Mechanism" section
109 Do not pipe Git output into a pager.
112 Set the path to the repository. This can also be controlled by
113 setting the `GIT_DIR` environment variable. It can be an absolute
114 path or relative path to current working directory.
117 Set the path to the working tree. It can be an absolute path
118 or a path relative to the current working directory.
119 This can also be controlled by setting the GIT_WORK_TREE
120 environment variable and the core.worktree configuration
121 variable (see core.worktree in linkgit:git-config[1] for a
122 more detailed discussion).
125 Set the Git namespace. See linkgit:gitnamespaces[7] for more
126 details. Equivalent to setting the `GIT_NAMESPACE` environment
129 --super-prefix=<path>::
130 Currently for internal use only. Set a prefix which gives a path from
131 above a repository down to its root. One use is to give submodules
132 context about the superproject that invoked it.
135 Treat the repository as a bare repository. If GIT_DIR
136 environment is not set, it is set to the current working
139 --no-replace-objects::
140 Do not use replacement refs to replace Git objects. See
141 linkgit:git-replace[1] for more information.
143 --literal-pathspecs::
144 Treat pathspecs literally (i.e. no globbing, no pathspec magic).
145 This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment
149 Add "glob" magic to all pathspec. This is equivalent to setting
150 the `GIT_GLOB_PATHSPECS` environment variable to `1`. Disabling
151 globbing on individual pathspecs can be done using pathspec
155 Add "literal" magic to all pathspec. This is equivalent to setting
156 the `GIT_NOGLOB_PATHSPECS` environment variable to `1`. Enabling
157 globbing on individual pathspecs can be done using pathspec
161 Add "icase" magic to all pathspec. This is equivalent to setting
162 the `GIT_ICASE_PATHSPECS` environment variable to `1`.
164 --no-optional-locks::
165 Do not perform optional operations that require locks. This is
166 equivalent to setting the `GIT_OPTIONAL_LOCKS` to `0`.
168 --list-cmds=group[,group...]::
169 List commands by group. This is an internal/experimental
170 option and may change or be removed in the future. Supported
171 groups are: builtins, parseopt (builtin commands that use
172 parse-options), main (all commands in libexec directory),
173 others (all other commands in `$PATH` that have git- prefix),
174 list-<category> (see categories in command-list.txt),
175 nohelpers (exclude helper commands), alias and config
176 (retrieve command list from config variable completion.commands)
181 We divide Git into high level ("porcelain") commands and low level
182 ("plumbing") commands.
184 High-level commands (porcelain)
185 -------------------------------
187 We separate the porcelain commands into the main commands and some
188 ancillary user utilities.
190 Main porcelain commands
191 ~~~~~~~~~~~~~~~~~~~~~~~
193 include::cmds-mainporcelain.txt[]
199 include::cmds-ancillarymanipulators.txt[]
203 include::cmds-ancillaryinterrogators.txt[]
206 Interacting with Others
207 ~~~~~~~~~~~~~~~~~~~~~~~
209 These commands are to interact with foreign SCM and with other
210 people via patch over e-mail.
212 include::cmds-foreignscminterface.txt[]
214 Reset, restore and revert
215 ~~~~~~~~~~~~~~~~~~~~~~~~~
216 There are three commands with similar names: `git reset`,
217 `git restore` and `git revert`.
219 * linkgit:git-revert[1] is about making a new commit that reverts the
220 changes made by other commits.
222 * linkgit:git-restore[1] is about restoring files in the working tree
223 from either the index or another commit. This command does not
224 update your branch. The command can also be used to restore files in
225 the index from another commit.
227 * linkgit:git-reset[1] is about updating your branch, moving the tip
228 in order to add or remove commits from the branch. This operation
229 changes the commit history.
231 `git reset` can also be used to restore the index, overlapping with
235 Low-level commands (plumbing)
236 -----------------------------
238 Although Git includes its
239 own porcelain layer, its low-level commands are sufficient to support
240 development of alternative porcelains. Developers of such porcelains
241 might start by reading about linkgit:git-update-index[1] and
242 linkgit:git-read-tree[1].
244 The interface (input, output, set of options and the semantics)
245 to these low-level commands are meant to be a lot more stable
246 than Porcelain level commands, because these commands are
247 primarily for scripted use. The interface to Porcelain commands
248 on the other hand are subject to change in order to improve the
251 The following description divides
252 the low-level commands into commands that manipulate objects (in
253 the repository, index, and working tree), commands that interrogate and
254 compare objects, and commands that move objects and references between
258 Manipulation commands
259 ~~~~~~~~~~~~~~~~~~~~~
261 include::cmds-plumbingmanipulators.txt[]
264 Interrogation commands
265 ~~~~~~~~~~~~~~~~~~~~~~
267 include::cmds-plumbinginterrogators.txt[]
269 In general, the interrogate commands do not touch the files in
273 Synching repositories
274 ~~~~~~~~~~~~~~~~~~~~~
276 include::cmds-synchingrepositories.txt[]
278 The following are helper commands used by the above; end users
279 typically do not use them directly.
281 include::cmds-synchelpers.txt[]
284 Internal helper commands
285 ~~~~~~~~~~~~~~~~~~~~~~~~
287 These are internal helper commands used by other commands; end
288 users typically do not use them directly.
290 include::cmds-purehelpers.txt[]
293 Configuration Mechanism
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
302 # A '#' or ';' character indicates a comment.
307 ; Don't trust file modes
312 name = "Junio C Hamano"
313 email = "gitster@pobox.com"
317 Various commands read from the configuration file and adjust
318 their operation accordingly. See linkgit:git-config[1] for a
319 list and more details about the configuration mechanism.
322 Identifier Terminology
323 ----------------------
325 Indicates the object name for any type of object.
328 Indicates a blob object name.
331 Indicates a tree object name.
334 Indicates a commit object name.
337 Indicates a tree, commit or tag object name. A
338 command that takes a <tree-ish> argument ultimately wants to
339 operate on a <tree> object but automatically dereferences
340 <commit> and <tag> objects that point at a <tree>.
343 Indicates a commit or tag object name. A
344 command that takes a <commit-ish> argument ultimately wants to
345 operate on a <commit> object but automatically dereferences
346 <tag> objects that point at a <commit>.
349 Indicates that an object type is required.
350 Currently one of: `blob`, `tree`, `commit`, or `tag`.
353 Indicates a filename - almost always relative to the
354 root of the tree structure `GIT_INDEX_FILE` describes.
358 Any Git command accepting any <object> can also use the following
362 indicates the head of the current branch.
366 (i.e. a `refs/tags/<tag>` reference).
370 (i.e. a `refs/heads/<head>` reference).
372 For a more complete list of ways to spell object names, see
373 "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
376 File/Directory Structure
377 ------------------------
379 Please see the linkgit:gitrepository-layout[5] document.
381 Read linkgit:githooks[5] for more details about each hook.
383 Higher level SCMs may provide and manage additional information in the
389 Please see linkgit:gitglossary[7].
392 Environment Variables
393 ---------------------
394 Various Git commands use the following environment variables:
398 These environment variables apply to 'all' core Git commands. Nb: it
399 is worth noting that they may be used/overridden by SCMS sitting above
400 Git so take care if using a foreign front-end.
403 This environment allows the specification of an alternate
404 index file. If not specified, the default of `$GIT_DIR/index`
407 `GIT_INDEX_VERSION`::
408 This environment variable allows the specification of an index
409 version for new repositories. It won't affect existing index
410 files. By default index file version 2 or 3 is used. See
411 linkgit:git-update-index[1] for more information.
413 `GIT_OBJECT_DIRECTORY`::
414 If the object storage directory is specified via this
415 environment variable then the sha1 directories are created
416 underneath - otherwise the default `$GIT_DIR/objects`
419 `GIT_ALTERNATE_OBJECT_DIRECTORIES`::
420 Due to the immutable nature of Git objects, old objects can be
421 archived into shared, read-only directories. This variable
422 specifies a ":" separated (on Windows ";" separated) list
423 of Git object directories which can be used to search for Git
424 objects. New objects will not be written to these directories.
426 Entries that begin with `"` (double-quote) will be interpreted
427 as C-style quoted paths, removing leading and trailing
428 double-quotes and respecting backslash escapes. E.g., the value
429 `"path-with-\"-and-:-in-it":vanilla-path` has two paths:
430 `path-with-"-and-:-in-it` and `vanilla-path`.
433 If the `GIT_DIR` environment variable is set then it
434 specifies a path to use instead of the default `.git`
435 for the base of the repository.
436 The `--git-dir` command-line option also sets this value.
439 Set the path to the root of the working tree.
440 This can also be controlled by the `--work-tree` command-line
441 option and the core.worktree configuration variable.
444 Set the Git namespace; see linkgit:gitnamespaces[7] for details.
445 The `--namespace` command-line option also sets this value.
447 `GIT_CEILING_DIRECTORIES`::
448 This should be a colon-separated list of absolute paths. If
449 set, it is a list of directories that Git should not chdir up
450 into while looking for a repository directory (useful for
451 excluding slow-loading network directories). It will not
452 exclude the current working directory or a GIT_DIR set on the
453 command line or in the environment. Normally, Git has to read
454 the entries in this list and resolve any symlink that
455 might be present in order to compare them with the current
456 directory. However, if even this access is slow, you
457 can add an empty entry to the list to tell Git that the
458 subsequent entries are not symlinks and needn't be resolved;
460 `GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink`.
462 `GIT_DISCOVERY_ACROSS_FILESYSTEM`::
463 When run in a directory that does not have ".git" repository
464 directory, Git tries to find such a directory in the parent
465 directories to find the top of the working tree, but by default it
466 does not cross filesystem boundaries. This environment variable
467 can be set to true to tell Git not to stop at filesystem
468 boundaries. Like `GIT_CEILING_DIRECTORIES`, this will not affect
469 an explicit repository directory set via `GIT_DIR` or on the
473 If this variable is set to a path, non-worktree files that are
474 normally in $GIT_DIR will be taken from this path
475 instead. Worktree-specific files such as HEAD or index are
476 taken from $GIT_DIR. See linkgit:gitrepository-layout[5] and
477 linkgit:git-worktree[1] for
478 details. This variable has lower precedence than other path
479 variables such as GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY...
486 `GIT_COMMITTER_NAME`::
487 `GIT_COMMITTER_EMAIL`::
488 `GIT_COMMITTER_DATE`::
490 see linkgit:git-commit-tree[1]
495 Only valid setting is "--unified=??" or "-u??" to set the
496 number of context lines shown when a unified diff is created.
497 This takes precedence over any "-U" or "--unified" option
498 value passed on the Git diff command line.
500 `GIT_EXTERNAL_DIFF`::
501 When the environment variable `GIT_EXTERNAL_DIFF` is set, the
502 program named by it is called, instead of the diff invocation
503 described above. For a path that is added, removed, or modified,
504 `GIT_EXTERNAL_DIFF` is called with 7 parameters:
506 path old-file old-hex old-mode new-file new-hex new-mode
510 <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
511 contents of <old|new>,
512 <old|new>-hex:: are the 40-hexdigit SHA-1 hashes,
513 <old|new>-mode:: are the octal representation of the file modes.
515 The file parameters can point at the user's working file
516 (e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file`
517 when a new file is added), or a temporary file (e.g. `old-file` in the
518 index). `GIT_EXTERNAL_DIFF` should not worry about unlinking the
519 temporary file --- it is removed when `GIT_EXTERNAL_DIFF` exits.
521 For a path that is unmerged, `GIT_EXTERNAL_DIFF` is called with 1
524 For each path `GIT_EXTERNAL_DIFF` is called, two environment variables,
525 `GIT_DIFF_PATH_COUNTER` and `GIT_DIFF_PATH_TOTAL` are set.
527 `GIT_DIFF_PATH_COUNTER`::
528 A 1-based counter incremented by one for every path.
530 `GIT_DIFF_PATH_TOTAL`::
531 The total number of paths.
535 `GIT_MERGE_VERBOSITY`::
536 A number controlling the amount of output shown by
537 the recursive merge strategy. Overrides merge.verbosity.
538 See linkgit:git-merge[1]
541 This environment variable overrides `$PAGER`. If it is set
542 to an empty string or to the value "cat", Git will not launch
543 a pager. See also the `core.pager` option in
544 linkgit:git-config[1].
547 This environment variable overrides `$EDITOR` and `$VISUAL`.
548 It is used by several Git commands when, on interactive mode,
549 an editor is to be launched. See also linkgit:git-var[1]
550 and the `core.editor` option in linkgit:git-config[1].
554 If either of these environment variables is set then 'git fetch'
555 and 'git push' will use the specified command instead of 'ssh'
556 when they need to connect to a remote system.
557 The command-line parameters passed to the configured command are
558 determined by the ssh variant. See `ssh.variant` option in
559 linkgit:git-config[1] for details.
561 `$GIT_SSH_COMMAND` takes precedence over `$GIT_SSH`, and is interpreted
562 by the shell, which allows additional arguments to be included.
563 `$GIT_SSH` on the other hand must be just the path to a program
564 (which can be a wrapper shell script, if additional arguments are
567 Usually it is easier to configure any desired options through your
568 personal `.ssh/config` file. Please consult your ssh documentation
572 If this environment variable is set, it overrides Git's autodetection
573 whether `GIT_SSH`/`GIT_SSH_COMMAND`/`core.sshCommand` refer to OpenSSH,
574 plink or tortoiseplink. This variable overrides the config setting
575 `ssh.variant` that serves the same purpose.
578 If this environment variable is set, then Git commands which need to
579 acquire passwords or passphrases (e.g. for HTTP or IMAP authentication)
580 will call this program with a suitable prompt as command-line argument
581 and read the password from its STDOUT. See also the `core.askPass`
582 option in linkgit:git-config[1].
584 `GIT_TERMINAL_PROMPT`::
585 If this environment variable is set to `0`, git will not prompt
586 on the terminal (e.g., when asking for HTTP authentication).
588 `GIT_CONFIG_NOSYSTEM`::
589 Whether to skip reading settings from the system-wide
590 `$(prefix)/etc/gitconfig` file. This environment variable can
591 be used along with `$HOME` and `$XDG_CONFIG_HOME` to create a
592 predictable environment for a picky script, or you can set it
593 temporarily to avoid using a buggy `/etc/gitconfig` file while
594 waiting for someone with sufficient permissions to fix it.
597 If this environment variable is set to "1", then commands such
598 as 'git blame' (in incremental mode), 'git rev-list', 'git log',
599 'git check-attr' and 'git check-ignore' will
600 force a flush of the output stream after each record have been
602 variable is set to "0", the output of these commands will be done
603 using completely buffered I/O. If this environment variable is
604 not set, Git will choose buffered or record-oriented flushing
605 based on whether stdout appears to be redirected to a file or not.
608 Enables general trace messages, e.g. alias expansion, built-in
609 command execution and external command execution.
611 If this variable is set to "1", "2" or "true" (comparison
612 is case insensitive), trace messages will be printed to
615 If the variable is set to an integer value greater than 2
616 and lower than 10 (strictly) then Git will interpret this
617 value as an open file descriptor and will try to write the
618 trace messages into this file descriptor.
620 Alternatively, if the variable is set to an absolute path
621 (starting with a '/' character), Git will interpret this
622 as a file path and will try to append the trace messages
625 Unsetting the variable, or setting it to empty, "0" or
626 "false" (case insensitive) disables trace messages.
628 `GIT_TRACE_FSMONITOR`::
629 Enables trace messages for the filesystem monitor extension.
630 See `GIT_TRACE` for available trace output options.
632 `GIT_TRACE_PACK_ACCESS`::
633 Enables trace messages for all accesses to any packs. For each
634 access, the pack file name and an offset in the pack is
635 recorded. This may be helpful for troubleshooting some
636 pack-related performance problems.
637 See `GIT_TRACE` for available trace output options.
640 Enables trace messages for all packets coming in or out of a
641 given program. This can help with debugging object negotiation
642 or other protocol issues. Tracing is turned off at a packet
643 starting with "PACK" (but see `GIT_TRACE_PACKFILE` below).
644 See `GIT_TRACE` for available trace output options.
646 `GIT_TRACE_PACKFILE`::
647 Enables tracing of packfiles sent or received by a
648 given program. Unlike other trace output, this trace is
649 verbatim: no headers, and no quoting of binary data. You almost
650 certainly want to direct into a file (e.g.,
651 `GIT_TRACE_PACKFILE=/tmp/my.pack`) rather than displaying it on
652 the terminal or mixing it with other trace output.
654 Note that this is currently only implemented for the client side
655 of clones and fetches.
657 `GIT_TRACE_PERFORMANCE`::
658 Enables performance related trace messages, e.g. total execution
659 time of each Git command.
660 See `GIT_TRACE` for available trace output options.
663 Enables trace messages printing the .git, working tree and current
664 working directory after Git has completed its setup phase.
665 See `GIT_TRACE` for available trace output options.
667 `GIT_TRACE_SHALLOW`::
668 Enables trace messages that can help debugging fetching /
669 cloning of shallow repositories.
670 See `GIT_TRACE` for available trace output options.
673 Enables a curl full trace dump of all incoming and outgoing data,
674 including descriptive information, of the git transport protocol.
675 This is similar to doing curl `--trace-ascii` on the command line.
676 This option overrides setting the `GIT_CURL_VERBOSE` environment
678 See `GIT_TRACE` for available trace output options.
680 `GIT_TRACE_CURL_NO_DATA`::
681 When a curl trace is enabled (see `GIT_TRACE_CURL` above), do not dump
682 data (that is, only dump info lines and headers).
685 Enables more detailed trace messages from the "trace2" library.
686 Output from `GIT_TRACE2` is a simple text-based format for human
689 If this variable is set to "1", "2" or "true" (comparison
690 is case insensitive), trace messages will be printed to
693 If the variable is set to an integer value greater than 2
694 and lower than 10 (strictly) then Git will interpret this
695 value as an open file descriptor and will try to write the
696 trace messages into this file descriptor.
698 Alternatively, if the variable is set to an absolute path
699 (starting with a '/' character), Git will interpret this
700 as a file path and will try to append the trace messages
701 to it. If the path already exists and is a directory, the
702 trace messages will be written to files (one per process)
703 in that directory, named according to the last component
704 of the SID and an optional counter (to avoid filename
707 In addition, if the variable is set to
708 `af_unix:[<socket_type>:]<absolute-pathname>`, Git will try
709 to open the path as a Unix Domain Socket. The socket type
710 can be either `stream` or `dgram`.
712 Unsetting the variable, or setting it to empty, "0" or
713 "false" (case insensitive) disables trace messages.
715 See link:technical/api-trace2.html[Trace2 documentation]
720 This setting writes a JSON-based format that is suited for machine
722 See `GIT_TRACE2` for available trace output options and
723 link:technical/api-trace2.html[Trace2 documentation] for full details.
726 In addition to the text-based messages available in `GIT_TRACE2`, this
727 setting writes a column-based format for understanding nesting
729 See `GIT_TRACE2` for available trace output options and
730 link:technical/api-trace2.html[Trace2 documentation] for full details.
732 `GIT_REDACT_COOKIES`::
733 This can be set to a comma-separated list of strings. When a curl trace
734 is enabled (see `GIT_TRACE_CURL` above), whenever a "Cookies:" header
735 sent by the client is dumped, values of cookies whose key is in that
736 list (case-sensitive) are redacted.
738 `GIT_LITERAL_PATHSPECS`::
739 Setting this variable to `1` will cause Git to treat all
740 pathspecs literally, rather than as glob patterns. For example,
741 running `GIT_LITERAL_PATHSPECS=1 git log -- '*.c'` will search
742 for commits that touch the path `*.c`, not any paths that the
743 glob `*.c` matches. You might want this if you are feeding
744 literal paths to Git (e.g., paths previously given to you by
745 `git ls-tree`, `--raw` diff output, etc).
747 `GIT_GLOB_PATHSPECS`::
748 Setting this variable to `1` will cause Git to treat all
749 pathspecs as glob patterns (aka "glob" magic).
751 `GIT_NOGLOB_PATHSPECS`::
752 Setting this variable to `1` will cause Git to treat all
753 pathspecs as literal (aka "literal" magic).
755 `GIT_ICASE_PATHSPECS`::
756 Setting this variable to `1` will cause Git to treat all
757 pathspecs as case-insensitive.
759 `GIT_REFLOG_ACTION`::
760 When a ref is updated, reflog entries are created to keep
761 track of the reason why the ref was updated (which is
762 typically the name of the high-level command that updated
763 the ref), in addition to the old and new values of the ref.
764 A scripted Porcelain command can use set_reflog_action
765 helper function in `git-sh-setup` to set its name to this
766 variable when it is invoked as the top level command by the
767 end user, to be recorded in the body of the reflog.
770 If set to `1`, include broken or badly named refs when iterating
771 over lists of refs. In a normal, non-corrupted repository, this
772 does nothing. However, enabling it may help git to detect and
773 abort some operations in the presence of broken refs. Git sets
774 this variable automatically when performing destructive
775 operations like linkgit:git-prune[1]. You should not need to set
776 it yourself unless you want to be paranoid about making sure
777 an operation has touched every ref (e.g., because you are
778 cloning a repository to make a backup).
780 `GIT_ALLOW_PROTOCOL`::
781 If set to a colon-separated list of protocols, behave as if
782 `protocol.allow` is set to `never`, and each of the listed
783 protocols has `protocol.<name>.allow` set to `always`
784 (overriding any existing configuration). In other words, any
785 protocol not mentioned will be disallowed (i.e., this is a
786 whitelist, not a blacklist). See the description of
787 `protocol.allow` in linkgit:git-config[1] for more details.
789 `GIT_PROTOCOL_FROM_USER`::
790 Set to 0 to prevent protocols used by fetch/push/clone which are
791 configured to the `user` state. This is useful to restrict recursive
792 submodule initialization from an untrusted repository or for programs
793 which feed potentially-untrusted URLS to git commands. See
794 linkgit:git-config[1] for more details.
797 For internal use only. Used in handshaking the wire protocol.
798 Contains a colon ':' separated list of keys with optional values
799 'key[=value]'. Presence of unknown keys and values must be
802 `GIT_OPTIONAL_LOCKS`::
803 If set to `0`, Git will complete any requested operation without
804 performing any optional sub-operations that require taking a lock.
805 For example, this will prevent `git status` from refreshing the
806 index as a side effect. This is useful for processes running in
807 the background which do not want to cause lock contention with
808 other operations on the repository. Defaults to `1`.
810 `GIT_REDIRECT_STDIN`::
811 `GIT_REDIRECT_STDOUT`::
812 `GIT_REDIRECT_STDERR`::
813 Windows-only: allow redirecting the standard input/output/error
814 handles to paths specified by the environment variables. This is
815 particularly useful in multi-threaded applications where the
816 canonical way to pass standard handles via `CreateProcess()` is
817 not an option because it would require the handles to be marked
818 inheritable (and consequently *every* spawned process would
819 inherit them, possibly blocking regular Git operations). The
820 primary intended use case is to use named pipes for communication
821 (e.g. `\\.\pipe\my-git-stdin-123`).
823 Two special values are supported: `off` will simply close the
824 corresponding standard handle, and if `GIT_REDIRECT_STDERR` is
825 `2>&1`, standard error will be redirected to the same handle as
828 `GIT_PRINT_SHA1_ELLIPSIS` (deprecated)::
829 If set to `yes`, print an ellipsis following an
830 (abbreviated) SHA-1 value. This affects indications of
831 detached HEADs (linkgit:git-checkout[1]) and the raw
832 diff output (linkgit:git-diff[1]). Printing an
833 ellipsis in the cases mentioned is no longer considered
834 adequate and support for it is likely to be removed in the
835 foreseeable future (along with the variable).
837 Discussion[[Discussion]]
838 ------------------------
840 More detail on the following is available from the
841 link:user-manual.html#git-concepts[Git concepts chapter of the
842 user-manual] and linkgit:gitcore-tutorial[7].
844 A Git project normally consists of a working directory with a ".git"
845 subdirectory at the top level. The .git directory contains, among other
846 things, a compressed object database representing the complete history
847 of the project, an "index" file which links that history to the current
848 contents of the working tree, and named pointers into that history such
849 as tags and branch heads.
851 The object database contains objects of three main types: blobs, which
852 hold file data; trees, which point to blobs and other trees to build up
853 directory hierarchies; and commits, which each reference a single tree
854 and some number of parent commits.
856 The commit, equivalent to what other systems call a "changeset" or
857 "version", represents a step in the project's history, and each parent
858 represents an immediately preceding step. Commits with more than one
859 parent represent merges of independent lines of development.
861 All objects are named by the SHA-1 hash of their contents, normally
862 written as a string of 40 hex digits. Such names are globally unique.
863 The entire history leading up to a commit can be vouched for by signing
864 just that commit. A fourth object type, the tag, is provided for this
867 When first created, objects are stored in individual files, but for
868 efficiency may later be compressed together into "pack files".
870 Named pointers called refs mark interesting points in history. A ref
871 may contain the SHA-1 name of an object or the name of another ref. Refs
872 with names beginning `ref/head/` contain the SHA-1 name of the most
873 recent commit (or "head") of a branch under development. SHA-1 names of
874 tags of interest are stored under `ref/tags/`. A special ref named
875 `HEAD` contains the name of the currently checked-out branch.
877 The index file is initialized with a list of all paths and, for each
878 path, a blob object and a set of attributes. The blob object represents
879 the contents of the file as of the head of the current branch. The
880 attributes (last modified time, size, etc.) are taken from the
881 corresponding file in the working tree. Subsequent changes to the
882 working tree can be found by comparing these attributes. The index may
883 be updated with new content, and new commits may be created from the
884 content stored in the index.
886 The index is also capable of storing multiple entries (called "stages")
887 for a given pathname. These stages are used to hold the various
888 unmerged version of a file when a merge is in progress.
890 FURTHER DOCUMENTATION
891 ---------------------
893 See the references in the "description" section to get started
894 using Git. The following is probably more detail than necessary
895 for a first-time user.
897 The link:user-manual.html#git-concepts[Git concepts chapter of the
898 user-manual] and linkgit:gitcore-tutorial[7] both provide
899 introductions to the underlying Git architecture.
901 See linkgit:gitworkflows[7] for an overview of recommended workflows.
903 See also the link:howto-index.html[howto] documents for some useful
906 The internals are documented in the
907 link:technical/api-index.html[Git API documentation].
909 Users migrating from CVS may also want to
910 read linkgit:gitcvs-migration[7].
915 Git was started by Linus Torvalds, and is currently maintained by Junio
916 C Hamano. Numerous contributions have come from the Git mailing list
917 <git@vger.kernel.org>. http://www.openhub.net/p/git/contributors/summary
918 gives you a more complete list of contributors.
920 If you have a clone of git.git itself, the
921 output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you
922 the authors for specific parts of the project.
927 Report bugs to the Git mailing list <git@vger.kernel.org> where the
928 development and maintenance is primarily done. You do not have to be
929 subscribed to the list to send a message there. See the list archive
930 at https://public-inbox.org/git for previous bug reports and other
933 Issues which are security relevant should be disclosed privately to
934 the Git Security mailing list <git-security@googlegroups.com>.
938 linkgit:gittutorial[7], linkgit:gittutorial-2[7],
939 linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
940 linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
941 linkgit:gitcli[7], link:user-manual.html[The Git User's Manual],
942 linkgit:gitworkflows[7]
946 Part of the linkgit:git[1] suite