c01477ab5ef78a9491b709d60d64998b8848d35d
   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