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