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