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