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