| git(1) |
| ====== |
| |
| NAME |
| ---- |
| git - the stupid content tracker |
| |
| |
| SYNOPSIS |
| -------- |
| [verse] |
| 'git' [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>] |
| [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] |
| [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare] |
| [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] |
| [--super-prefix=<path>] [--config-env=<name>=<envvar>] |
| <command> [<args>] |
| |
| DESCRIPTION |
| ----------- |
| Git is a fast, scalable, distributed revision control system with an |
| unusually rich command set that provides both high-level operations |
| and full access to internals. |
| |
| See linkgit:gittutorial[7] to get started, then see |
| linkgit:giteveryday[7] for a useful minimum set of |
| commands. The link:user-manual.html[Git User's Manual] has a more |
| in-depth introduction. |
| |
| After you mastered the basic concepts, you can come back to this |
| page to learn what commands Git offers. You can learn more about |
| individual Git commands with "git help command". linkgit:gitcli[7] |
| manual page gives you an overview of the command-line command syntax. |
| |
| A formatted and hyperlinked copy of the latest Git documentation |
| can be viewed at https://git.github.io/htmldocs/git.html |
| or https://git-scm.com/docs. |
| |
| |
| OPTIONS |
| ------- |
| -v:: |
| --version:: |
| Prints the Git suite version that the 'git' program came from. |
| + |
| This option is internally converted to `git version ...` and accepts |
| the same options as the linkgit:git-version[1] command. If `--help` is |
| also given, it takes precedence over `--version`. |
| |
| -h:: |
| --help:: |
| Prints the synopsis and a list of the most commonly used |
| commands. If the option `--all` or `-a` is given then all |
| available commands are printed. If a Git command is named this |
| option will bring up the manual page for that command. |
| + |
| Other options are available to control how the manual page is |
| displayed. See linkgit:git-help[1] for more information, |
| because `git --help ...` is converted internally into `git |
| help ...`. |
| |
| -C <path>:: |
| Run as if git was started in '<path>' instead of the current working |
| directory. When multiple `-C` options are given, each subsequent |
| non-absolute `-C <path>` is interpreted relative to the preceding `-C |
| <path>`. If '<path>' is present but empty, e.g. `-C ""`, then the |
| current working directory is left unchanged. |
| + |
| This option affects options that expect path name like `--git-dir` and |
| `--work-tree` in that their interpretations of the path names would be |
| made relative to the working directory caused by the `-C` option. For |
| example the following invocations are equivalent: |
| |
| git --git-dir=a.git --work-tree=b -C c status |
| git --git-dir=c/a.git --work-tree=c/b status |
| |
| -c <name>=<value>:: |
| Pass a configuration parameter to the command. The value |
| given will override values from configuration files. |
| The <name> is expected in the same format as listed by |
| 'git config' (subkeys separated by dots). |
| + |
| Note that omitting the `=` in `git -c foo.bar ...` is allowed and sets |
| `foo.bar` to the boolean true value (just like `[foo]bar` would in a |
| config file). Including the equals but with an empty value (like `git -c |
| foo.bar= ...`) sets `foo.bar` to the empty string which `git config |
| --type=bool` will convert to `false`. |
| |
| --config-env=<name>=<envvar>:: |
| Like `-c <name>=<value>`, give configuration variable |
| '<name>' a value, where <envvar> is the name of an |
| environment variable from which to retrieve the value. Unlike |
| `-c` there is no shortcut for directly setting the value to an |
| empty string, instead the environment variable itself must be |
| set to the empty string. It is an error if the `<envvar>` does not exist |
| in the environment. `<envvar>` may not contain an equals sign |
| to avoid ambiguity with `<name>` containing one. |
| + |
| This is useful for cases where you want to pass transitory |
| configuration options to git, but are doing so on OS's where |
| other processes might be able to read your cmdline |
| (e.g. `/proc/self/cmdline`), but not your environ |
| (e.g. `/proc/self/environ`). That behavior is the default on |
| Linux, but may not be on your system. |
| + |
| Note that this might add security for variables such as |
| `http.extraHeader` where the sensitive information is part of |
| the value, but not e.g. `url.<base>.insteadOf` where the |
| sensitive information can be part of the key. |
| |
| --exec-path[=<path>]:: |
| Path to wherever your core Git programs are installed. |
| This can also be controlled by setting the GIT_EXEC_PATH |
| environment variable. If no path is given, 'git' will print |
| the current setting and then exit. |
| |
| --html-path:: |
| Print the path, without trailing slash, where Git's HTML |
| documentation is installed and exit. |
| |
| --man-path:: |
| Print the manpath (see `man(1)`) for the man pages for |
| this version of Git and exit. |
| |
| --info-path:: |
| Print the path where the Info files documenting this |
| version of Git are installed and exit. |
| |
| -p:: |
| --paginate:: |
| Pipe all output into 'less' (or if set, $PAGER) if standard |
| output is a terminal. This overrides the `pager.<cmd>` |
| configuration options (see the "Configuration Mechanism" section |
| below). |
| |
| -P:: |
| --no-pager:: |
| Do not pipe Git output into a pager. |
| |
| --git-dir=<path>:: |
| Set the path to the repository (".git" directory). This can also be |
| controlled by setting the `GIT_DIR` environment variable. It can be |
| an absolute path or relative path to current working directory. |
| + |
| Specifying the location of the ".git" directory using this |
| option (or `GIT_DIR` environment variable) turns off the |
| repository discovery that tries to find a directory with |
| ".git" subdirectory (which is how the repository and the |
| top-level of the working tree are discovered), and tells Git |
| that you are at the top level of the working tree. If you |
| are not at the top-level directory of the working tree, you |
| should tell Git where the top-level of the working tree is, |
| with the `--work-tree=<path>` option (or `GIT_WORK_TREE` |
| environment variable) |
| + |
| If you just want to run git as if it was started in `<path>` then use |
| `git -C <path>`. |
| |
| --work-tree=<path>:: |
| Set the path to the working tree. It can be an absolute path |
| or a path relative to the current working directory. |
| This can also be controlled by setting the GIT_WORK_TREE |
| environment variable and the core.worktree configuration |
| variable (see core.worktree in linkgit:git-config[1] for a |
| more detailed discussion). |
| |
| --namespace=<path>:: |
| Set the Git namespace. See linkgit:gitnamespaces[7] for more |
| details. Equivalent to setting the `GIT_NAMESPACE` environment |
| variable. |
| |
| --super-prefix=<path>:: |
| Currently for internal use only. Set a prefix which gives a path from |
| above a repository down to its root. One use is to give submodules |
| context about the superproject that invoked it. |
| |
| --bare:: |
| Treat the repository as a bare repository. If GIT_DIR |
| environment is not set, it is set to the current working |
| directory. |
| |
| --no-replace-objects:: |
| Do not use replacement refs to replace Git objects. See |
| linkgit:git-replace[1] for more information. |
| |
| --literal-pathspecs:: |
| Treat pathspecs literally (i.e. no globbing, no pathspec magic). |
| This is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment |
| variable to `1`. |
| |
| --glob-pathspecs:: |
| Add "glob" magic to all pathspec. This is equivalent to setting |
| the `GIT_GLOB_PATHSPECS` environment variable to `1`. Disabling |
| globbing on individual pathspecs can be done using pathspec |
| magic ":(literal)" |
| |
| --noglob-pathspecs:: |
| Add "literal" magic to all pathspec. This is equivalent to setting |
| the `GIT_NOGLOB_PATHSPECS` environment variable to `1`. Enabling |
| globbing on individual pathspecs can be done using pathspec |
| magic ":(glob)" |
| |
| --icase-pathspecs:: |
| Add "icase" magic to all pathspec. This is equivalent to setting |
| the `GIT_ICASE_PATHSPECS` environment variable to `1`. |
| |
| --no-optional-locks:: |
| Do not perform optional operations that require locks. This is |
| equivalent to setting the `GIT_OPTIONAL_LOCKS` to `0`. |
| |
| --list-cmds=group[,group...]:: |
| List commands by group. This is an internal/experimental |
| option and may change or be removed in the future. Supported |
| groups are: builtins, parseopt (builtin commands that use |
| parse-options), main (all commands in libexec directory), |
| others (all other commands in `$PATH` that have git- prefix), |
| list-<category> (see categories in command-list.txt), |
| nohelpers (exclude helper commands), alias and config |
| (retrieve command list from config variable completion.commands) |
| |
| GIT COMMANDS |
| ------------ |
| |
| We divide Git into high level ("porcelain") commands and low level |
| ("plumbing") commands. |
| |
| High-level commands (porcelain) |
| ------------------------------- |
| |
| We separate the porcelain commands into the main commands and some |
| ancillary user utilities. |
| |
| Main porcelain commands |
| ~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| include::cmds-mainporcelain.txt[] |
| |
| Ancillary Commands |
| ~~~~~~~~~~~~~~~~~~ |
| Manipulators: |
| |
| include::cmds-ancillarymanipulators.txt[] |
| |
| Interrogators: |
| |
| include::cmds-ancillaryinterrogators.txt[] |
| |
| |
| Interacting with Others |
| ~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| These commands are to interact with foreign SCM and with other |
| people via patch over e-mail. |
| |
| include::cmds-foreignscminterface.txt[] |
| |
| Reset, restore and revert |
| ~~~~~~~~~~~~~~~~~~~~~~~~~ |
| There are three commands with similar names: `git reset`, |
| `git restore` and `git revert`. |
| |
| * linkgit:git-revert[1] is about making a new commit that reverts the |
| changes made by other commits. |
| |
| * linkgit:git-restore[1] is about restoring files in the working tree |
| from either the index or another commit. This command does not |
| update your branch. The command can also be used to restore files in |
| the index from another commit. |
| |
| * linkgit:git-reset[1] is about updating your branch, moving the tip |
| in order to add or remove commits from the branch. This operation |
| changes the commit history. |
| + |
| `git reset` can also be used to restore the index, overlapping with |
| `git restore`. |
| |
| |
| Low-level commands (plumbing) |
| ----------------------------- |
| |
| Although Git includes its |
| own porcelain layer, its low-level commands are sufficient to support |
| development of alternative porcelains. Developers of such porcelains |
| might start by reading about linkgit:git-update-index[1] and |
| linkgit:git-read-tree[1]. |
| |
| The interface (input, output, set of options and the semantics) |
| to these low-level commands are meant to be a lot more stable |
| than Porcelain level commands, because these commands are |
| primarily for scripted use. The interface to Porcelain commands |
| on the other hand are subject to change in order to improve the |
| end user experience. |
| |
| The following description divides |
| the low-level commands into commands that manipulate objects (in |
| the repository, index, and working tree), commands that interrogate and |
| compare objects, and commands that move objects and references between |
| repositories. |
| |
| |
| Manipulation commands |
| ~~~~~~~~~~~~~~~~~~~~~ |
| |
| include::cmds-plumbingmanipulators.txt[] |
| |
| |
| Interrogation commands |
| ~~~~~~~~~~~~~~~~~~~~~~ |
| |
| include::cmds-plumbinginterrogators.txt[] |
| |
| In general, the interrogate commands do not touch the files in |
| the working tree. |
| |
| |
| Syncing repositories |
| ~~~~~~~~~~~~~~~~~~~~ |
| |
| include::cmds-synchingrepositories.txt[] |
| |
| The following are helper commands used by the above; end users |
| typically do not use them directly. |
| |
| include::cmds-synchelpers.txt[] |
| |
| |
| Internal helper commands |
| ~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| These are internal helper commands used by other commands; end |
| users typically do not use them directly. |
| |
| include::cmds-purehelpers.txt[] |
| |
| Guides |
| ------ |
| |
| The following documentation pages are guides about Git concepts. |
| |
| include::cmds-guide.txt[] |
| |
| |
| Configuration Mechanism |
| ----------------------- |
| |
| Git uses a simple text format to store customizations that are per |
| repository and are per user. Such a configuration file may look |
| like this: |
| |
| ------------ |
| # |
| # A '#' or ';' character indicates a comment. |
| # |
| |
| ; core variables |
| [core] |
| ; Don't trust file modes |
| filemode = false |
| |
| ; user identity |
| [user] |
| name = "Junio C Hamano" |
| email = "gitster@pobox.com" |
| |
| ------------ |
| |
| Various commands read from the configuration file and adjust |
| their operation accordingly. See linkgit:git-config[1] for a |
| list and more details about the configuration mechanism. |
| |
| |
| Identifier Terminology |
| ---------------------- |
| <object>:: |
| Indicates the object name for any type of object. |
| |
| <blob>:: |
| Indicates a blob object name. |
| |
| <tree>:: |
| Indicates a tree object name. |
| |
| <commit>:: |
| Indicates a commit object name. |
| |
| <tree-ish>:: |
| Indicates a tree, commit or tag object name. A |
| command that takes a <tree-ish> argument ultimately wants to |
| operate on a <tree> object but automatically dereferences |
| <commit> and <tag> objects that point at a <tree>. |
| |
| <commit-ish>:: |
| Indicates a commit or tag object name. A |
| command that takes a <commit-ish> argument ultimately wants to |
| operate on a <commit> object but automatically dereferences |
| <tag> objects that point at a <commit>. |
| |
| <type>:: |
| Indicates that an object type is required. |
| Currently one of: `blob`, `tree`, `commit`, or `tag`. |
| |
| <file>:: |
| Indicates a filename - almost always relative to the |
| root of the tree structure `GIT_INDEX_FILE` describes. |
| |
| Symbolic Identifiers |
| -------------------- |
| Any Git command accepting any <object> can also use the following |
| symbolic notation: |
| |
| HEAD:: |
| indicates the head of the current branch. |
| |
| <tag>:: |
| a valid tag 'name' |
| (i.e. a `refs/tags/<tag>` reference). |
| |
| <head>:: |
| a valid head 'name' |
| (i.e. a `refs/heads/<head>` reference). |
| |
| For a more complete list of ways to spell object names, see |
| "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7]. |
| |
| |
| File/Directory Structure |
| ------------------------ |
| |
| Please see the linkgit:gitrepository-layout[5] document. |
| |
| Read linkgit:githooks[5] for more details about each hook. |
| |
| Higher level SCMs may provide and manage additional information in the |
| `$GIT_DIR`. |
| |
| |
| Terminology |
| ----------- |
| Please see linkgit:gitglossary[7]. |
| |
| |
| Environment Variables |
| --------------------- |
| Various Git commands use the following environment variables: |
| |
| The Git Repository |
| ~~~~~~~~~~~~~~~~~~ |
| These environment variables apply to 'all' core Git commands. Nb: it |
| is worth noting that they may be used/overridden by SCMS sitting above |
| Git so take care if using a foreign front-end. |
| |
| `GIT_INDEX_FILE`:: |
| This environment allows the specification of an alternate |
| index file. If not specified, the default of `$GIT_DIR/index` |
| is used. |
| |
| `GIT_INDEX_VERSION`:: |
| This environment variable allows the specification of an index |
| version for new repositories. It won't affect existing index |
| files. By default index file version 2 or 3 is used. See |
| linkgit:git-update-index[1] for more information. |
| |
| `GIT_OBJECT_DIRECTORY`:: |
| If the object storage directory is specified via this |
| environment variable then the sha1 directories are created |
| underneath - otherwise the default `$GIT_DIR/objects` |
| directory is used. |
| |
| `GIT_ALTERNATE_OBJECT_DIRECTORIES`:: |
| Due to the immutable nature of Git objects, old objects can be |
| archived into shared, read-only directories. This variable |
| specifies a ":" separated (on Windows ";" separated) list |
| of Git object directories which can be used to search for Git |
| objects. New objects will not be written to these directories. |
| + |
| Entries that begin with `"` (double-quote) will be interpreted |
| as C-style quoted paths, removing leading and trailing |
| double-quotes and respecting backslash escapes. E.g., the value |
| `"path-with-\"-and-:-in-it":vanilla-path` has two paths: |
| `path-with-"-and-:-in-it` and `vanilla-path`. |
| |
| `GIT_DIR`:: |
| If the `GIT_DIR` environment variable is set then it |
| specifies a path to use instead of the default `.git` |
| for the base of the repository. |
| The `--git-dir` command-line option also sets this value. |
| |
| `GIT_WORK_TREE`:: |
| Set the path to the root of the working tree. |
| This can also be controlled by the `--work-tree` command-line |
| option and the core.worktree configuration variable. |
| |
| `GIT_NAMESPACE`:: |
| Set the Git namespace; see linkgit:gitnamespaces[7] for details. |
| The `--namespace` command-line option also sets this value. |
| |
| `GIT_CEILING_DIRECTORIES`:: |
| This should be a colon-separated list of absolute paths. If |
| set, it is a list of directories that Git should not chdir up |
| into while looking for a repository directory (useful for |
| excluding slow-loading network directories). It will not |
| exclude the current working directory or a GIT_DIR set on the |
| command line or in the environment. Normally, Git has to read |
| the entries in this list and resolve any symlink that |
| might be present in order to compare them with the current |
| directory. However, if even this access is slow, you |
| can add an empty entry to the list to tell Git that the |
| subsequent entries are not symlinks and needn't be resolved; |
| e.g., |
| `GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink`. |
| |
| `GIT_DISCOVERY_ACROSS_FILESYSTEM`:: |
| When run in a directory that does not have ".git" repository |
| directory, Git tries to find such a directory in the parent |
| directories to find the top of the working tree, but by default it |
| does not cross filesystem boundaries. This environment variable |
| can be set to true to tell Git not to stop at filesystem |
| boundaries. Like `GIT_CEILING_DIRECTORIES`, this will not affect |
| an explicit repository directory set via `GIT_DIR` or on the |
| command line. |
| |
| `GIT_COMMON_DIR`:: |
| If this variable is set to a path, non-worktree files that are |
| normally in $GIT_DIR will be taken from this path |
| instead. Worktree-specific files such as HEAD or index are |
| taken from $GIT_DIR. See linkgit:gitrepository-layout[5] and |
| linkgit:git-worktree[1] for |
| details. This variable has lower precedence than other path |
| variables such as GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY... |
| |
| `GIT_DEFAULT_HASH`:: |
| If this variable is set, the default hash algorithm for new |
| repositories will be set to this value. This value is currently |
| ignored when cloning; the setting of the remote repository |
| is used instead. The default is "sha1". THIS VARIABLE IS |
| EXPERIMENTAL! See `--object-format` in linkgit:git-init[1]. |
| |
| Git Commits |
| ~~~~~~~~~~~ |
| `GIT_AUTHOR_NAME`:: |
| The human-readable name used in the author identity when creating commit or |
| tag objects, or when writing reflogs. Overrides the `user.name` and |
| `author.name` configuration settings. |
| |
| `GIT_AUTHOR_EMAIL`:: |
| The email address used in the author identity when creating commit or |
| tag objects, or when writing reflogs. Overrides the `user.email` and |
| `author.email` configuration settings. |
| |
| `GIT_AUTHOR_DATE`:: |
| The date used for the author identity when creating commit or tag objects, or |
| when writing reflogs. See linkgit:git-commit[1] for valid formats. |
| |
| `GIT_COMMITTER_NAME`:: |
| The human-readable name used in the committer identity when creating commit or |
| tag objects, or when writing reflogs. Overrides the `user.name` and |
| `committer.name` configuration settings. |
| |
| `GIT_COMMITTER_EMAIL`:: |
| The email address used in the author identity when creating commit or |
| tag objects, or when writing reflogs. Overrides the `user.email` and |
| `committer.email` configuration settings. |
| |
| `GIT_COMMITTER_DATE`:: |
| The date used for the committer identity when creating commit or tag objects, or |
| when writing reflogs. See linkgit:git-commit[1] for valid formats. |
| |
| `EMAIL`:: |
| The email address used in the author and committer identities if no other |
| relevant environment variable or configuration setting has been set. |
| |
| Git Diffs |
| ~~~~~~~~~ |
| `GIT_DIFF_OPTS`:: |
| Only valid setting is "--unified=??" or "-u??" to set the |
| number of context lines shown when a unified diff is created. |
| This takes precedence over any "-U" or "--unified" option |
| value passed on the Git diff command line. |
| |
| `GIT_EXTERNAL_DIFF`:: |
| When the environment variable `GIT_EXTERNAL_DIFF` is set, the |
| program named by it is called to generate diffs, and Git |
| does not use its builtin diff machinery. |
| For a path that is added, removed, or modified, |
| `GIT_EXTERNAL_DIFF` is called with 7 parameters: |
| |
| path old-file old-hex old-mode new-file new-hex new-mode |
| + |
| where: |
| |
| <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the |
| contents of <old|new>, |
| <old|new>-hex:: are the 40-hexdigit SHA-1 hashes, |
| <old|new>-mode:: are the octal representation of the file modes. |
| + |
| The file parameters can point at the user's working file |
| (e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file` |
| when a new file is added), or a temporary file (e.g. `old-file` in the |
| index). `GIT_EXTERNAL_DIFF` should not worry about unlinking the |
| temporary file --- it is removed when `GIT_EXTERNAL_DIFF` exits. |
| + |
| For a path that is unmerged, `GIT_EXTERNAL_DIFF` is called with 1 |
| parameter, <path>. |
| + |
| For each path `GIT_EXTERNAL_DIFF` is called, two environment variables, |
| `GIT_DIFF_PATH_COUNTER` and `GIT_DIFF_PATH_TOTAL` are set. |
| |
| `GIT_DIFF_PATH_COUNTER`:: |
| A 1-based counter incremented by one for every path. |
| |
| `GIT_DIFF_PATH_TOTAL`:: |
| The total number of paths. |
| |
| other |
| ~~~~~ |
| `GIT_MERGE_VERBOSITY`:: |
| A number controlling the amount of output shown by |
| the recursive merge strategy. Overrides merge.verbosity. |
| See linkgit:git-merge[1] |
| |
| `GIT_PAGER`:: |
| This environment variable overrides `$PAGER`. If it is set |
| to an empty string or to the value "cat", Git will not launch |
| a pager. See also the `core.pager` option in |
| linkgit:git-config[1]. |
| |
| `GIT_PROGRESS_DELAY`:: |
| A number controlling how many seconds to delay before showing |
| optional progress indicators. Defaults to 2. |
| |
| `GIT_EDITOR`:: |
| This environment variable overrides `$EDITOR` and `$VISUAL`. |
| It is used by several Git commands when, on interactive mode, |
| an editor is to be launched. See also linkgit:git-var[1] |
| and the `core.editor` option in linkgit:git-config[1]. |
| |
| `GIT_SEQUENCE_EDITOR`:: |
| This environment variable overrides the configured Git editor |
| when editing the todo list of an interactive rebase. See also |
| linkgit:git-rebase[1] and the `sequence.editor` option in |
| linkgit:git-config[1]. |
| |
| `GIT_SSH`:: |
| `GIT_SSH_COMMAND`:: |
| If either of these environment variables is set then 'git fetch' |
| and 'git push' will use the specified command instead of 'ssh' |
| when they need to connect to a remote system. |
| The command-line parameters passed to the configured command are |
| determined by the ssh variant. See `ssh.variant` option in |
| linkgit:git-config[1] for details. |
| + |
| `$GIT_SSH_COMMAND` takes precedence over `$GIT_SSH`, and is interpreted |
| by the shell, which allows additional arguments to be included. |
| `$GIT_SSH` on the other hand must be just the path to a program |
| (which can be a wrapper shell script, if additional arguments are |
| needed). |
| + |
| Usually it is easier to configure any desired options through your |
| personal `.ssh/config` file. Please consult your ssh documentation |
| for further details. |
| |
| `GIT_SSH_VARIANT`:: |
| If this environment variable is set, it overrides Git's autodetection |
| whether `GIT_SSH`/`GIT_SSH_COMMAND`/`core.sshCommand` refer to OpenSSH, |
| plink or tortoiseplink. This variable overrides the config setting |
| `ssh.variant` that serves the same purpose. |
| |
| `GIT_ASKPASS`:: |
| If this environment variable is set, then Git commands which need to |
| acquire passwords or passphrases (e.g. for HTTP or IMAP authentication) |
| will call this program with a suitable prompt as command-line argument |
| and read the password from its STDOUT. See also the `core.askPass` |
| option in linkgit:git-config[1]. |
| |
| `GIT_TERMINAL_PROMPT`:: |
| If this environment variable is set to `0`, git will not prompt |
| on the terminal (e.g., when asking for HTTP authentication). |
| |
| `GIT_CONFIG_GLOBAL`:: |
| `GIT_CONFIG_SYSTEM`:: |
| Take the configuration from the given files instead from global or |
| system-level configuration files. If `GIT_CONFIG_SYSTEM` is set, the |
| system config file defined at build time (usually `/etc/gitconfig`) |
| will not be read. Likewise, if `GIT_CONFIG_GLOBAL` is set, neither |
| `$HOME/.gitconfig` nor `$XDG_CONFIG_HOME/git/config` will be read. Can |
| be set to `/dev/null` to skip reading configuration files of the |
| respective level. |
| |
| `GIT_CONFIG_NOSYSTEM`:: |
| Whether to skip reading settings from the system-wide |
| `$(prefix)/etc/gitconfig` file. This environment variable can |
| be used along with `$HOME` and `$XDG_CONFIG_HOME` to create a |
| predictable environment for a picky script, or you can set it |
| temporarily to avoid using a buggy `/etc/gitconfig` file while |
| waiting for someone with sufficient permissions to fix it. |
| |
| `GIT_FLUSH`:: |
| If this environment variable is set to "1", then commands such |
| as 'git blame' (in incremental mode), 'git rev-list', 'git log', |
| 'git check-attr' and 'git check-ignore' will |
| force a flush of the output stream after each record have been |
| flushed. If this |
| variable is set to "0", the output of these commands will be done |
| using completely buffered I/O. If this environment variable is |
| not set, Git will choose buffered or record-oriented flushing |
| based on whether stdout appears to be redirected to a file or not. |
| |
| `GIT_TRACE`:: |
| Enables general trace messages, e.g. alias expansion, built-in |
| command execution and external command execution. |
| + |
| If this variable is set to "1", "2" or "true" (comparison |
| is case insensitive), trace messages will be printed to |
| stderr. |
| + |
| If the variable is set to an integer value greater than 2 |
| and lower than 10 (strictly) then Git will interpret this |
| value as an open file descriptor and will try to write the |
| trace messages into this file descriptor. |
| + |
| Alternatively, if the variable is set to an absolute path |
| (starting with a '/' character), Git will interpret this |
| as a file path and will try to append the trace messages |
| to it. |
| + |
| Unsetting the variable, or setting it to empty, "0" or |
| "false" (case insensitive) disables trace messages. |
| |
| `GIT_TRACE_FSMONITOR`:: |
| Enables trace messages for the filesystem monitor extension. |
| See `GIT_TRACE` for available trace output options. |
| |
| `GIT_TRACE_PACK_ACCESS`:: |
| Enables trace messages for all accesses to any packs. For each |
| access, the pack file name and an offset in the pack is |
| recorded. This may be helpful for troubleshooting some |
| pack-related performance problems. |
| See `GIT_TRACE` for available trace output options. |
| |
| `GIT_TRACE_PACKET`:: |
| Enables trace messages for all packets coming in or out of a |
| given program. This can help with debugging object negotiation |
| or other protocol issues. Tracing is turned off at a packet |
| starting with "PACK" (but see `GIT_TRACE_PACKFILE` below). |
| See `GIT_TRACE` for available trace output options. |
| |
| `GIT_TRACE_PACKFILE`:: |
| Enables tracing of packfiles sent or received by a |
| given program. Unlike other trace output, this trace is |
| verbatim: no headers, and no quoting of binary data. You almost |
| certainly want to direct into a file (e.g., |
| `GIT_TRACE_PACKFILE=/tmp/my.pack`) rather than displaying it on |
| the terminal or mixing it with other trace output. |
| + |
| Note that this is currently only implemented for the client side |
| of clones and fetches. |
| |
| `GIT_TRACE_PERFORMANCE`:: |
| Enables performance related trace messages, e.g. total execution |
| time of each Git command. |
| See `GIT_TRACE` for available trace output options. |
| |
| `GIT_TRACE_REFS`:: |
| Enables trace messages for operations on the ref database. |
| See `GIT_TRACE` for available trace output options. |
| |
| `GIT_TRACE_SETUP`:: |
| Enables trace messages printing the .git, working tree and current |
| working directory after Git has completed its setup phase. |
| See `GIT_TRACE` for available trace output options. |
| |
| `GIT_TRACE_SHALLOW`:: |
| Enables trace messages that can help debugging fetching / |
| cloning of shallow repositories. |
| See `GIT_TRACE` for available trace output options. |
| |
| `GIT_TRACE_CURL`:: |
| Enables a curl full trace dump of all incoming and outgoing data, |
| including descriptive information, of the git transport protocol. |
| This is similar to doing curl `--trace-ascii` on the command line. |
| See `GIT_TRACE` for available trace output options. |
| |
| `GIT_TRACE_CURL_NO_DATA`:: |
| When a curl trace is enabled (see `GIT_TRACE_CURL` above), do not dump |
| data (that is, only dump info lines and headers). |
| |
| `GIT_TRACE2`:: |
| Enables more detailed trace messages from the "trace2" library. |
| Output from `GIT_TRACE2` is a simple text-based format for human |
| readability. |
| + |
| If this variable is set to "1", "2" or "true" (comparison |
| is case insensitive), trace messages will be printed to |
| stderr. |
| + |
| If the variable is set to an integer value greater than 2 |
| and lower than 10 (strictly) then Git will interpret this |
| value as an open file descriptor and will try to write the |
| trace messages into this file descriptor. |
| + |
| Alternatively, if the variable is set to an absolute path |
| (starting with a '/' character), Git will interpret this |
| as a file path and will try to append the trace messages |
| to it. If the path already exists and is a directory, the |
| trace messages will be written to files (one per process) |
| in that directory, named according to the last component |
| of the SID and an optional counter (to avoid filename |
| collisions). |
| + |
| In addition, if the variable is set to |
| `af_unix:[<socket_type>:]<absolute-pathname>`, Git will try |
| to open the path as a Unix Domain Socket. The socket type |
| can be either `stream` or `dgram`. |
| + |
| Unsetting the variable, or setting it to empty, "0" or |
| "false" (case insensitive) disables trace messages. |
| + |
| See link:technical/api-trace2.html[Trace2 documentation] |
| for full details. |
| |
| |
| `GIT_TRACE2_EVENT`:: |
| This setting writes a JSON-based format that is suited for machine |
| interpretation. |
| See `GIT_TRACE2` for available trace output options and |
| link:technical/api-trace2.html[Trace2 documentation] for full details. |
| |
| `GIT_TRACE2_PERF`:: |
| In addition to the text-based messages available in `GIT_TRACE2`, this |
| setting writes a column-based format for understanding nesting |
| regions. |
| See `GIT_TRACE2` for available trace output options and |
| link:technical/api-trace2.html[Trace2 documentation] for full details. |
| |
| `GIT_TRACE_REDACT`:: |
| By default, when tracing is activated, Git redacts the values of |
| cookies, the "Authorization:" header, the "Proxy-Authorization:" |
| header and packfile URIs. Set this variable to `0` to prevent this |
| redaction. |
| |
| `GIT_LITERAL_PATHSPECS`:: |
| Setting this variable to `1` will cause Git to treat all |
| pathspecs literally, rather than as glob patterns. For example, |
| running `GIT_LITERAL_PATHSPECS=1 git log -- '*.c'` will search |
| for commits that touch the path `*.c`, not any paths that the |
| glob `*.c` matches. You might want this if you are feeding |
| literal paths to Git (e.g., paths previously given to you by |
| `git ls-tree`, `--raw` diff output, etc). |
| |
| `GIT_GLOB_PATHSPECS`:: |
| Setting this variable to `1` will cause Git to treat all |
| pathspecs as glob patterns (aka "glob" magic). |
| |
| `GIT_NOGLOB_PATHSPECS`:: |
| Setting this variable to `1` will cause Git to treat all |
| pathspecs as literal (aka "literal" magic). |
| |
| `GIT_ICASE_PATHSPECS`:: |
| Setting this variable to `1` will cause Git to treat all |
| pathspecs as case-insensitive. |
| |
| `GIT_REFLOG_ACTION`:: |
| When a ref is updated, reflog entries are created to keep |
| track of the reason why the ref was updated (which is |
| typically the name of the high-level command that updated |
| the ref), in addition to the old and new values of the ref. |
| A scripted Porcelain command can use set_reflog_action |
| helper function in `git-sh-setup` to set its name to this |
| variable when it is invoked as the top level command by the |
| end user, to be recorded in the body of the reflog. |
| |
| `GIT_REF_PARANOIA`:: |
| If set to `0`, ignore broken or badly named refs when iterating |
| over lists of refs. Normally Git will try to include any such |
| refs, which may cause some operations to fail. This is usually |
| preferable, as potentially destructive operations (e.g., |
| linkgit:git-prune[1]) are better off aborting rather than |
| ignoring broken refs (and thus considering the history they |
| point to as not worth saving). The default value is `1` (i.e., |
| be paranoid about detecting and aborting all operations). You |
| should not normally need to set this to `0`, but it may be |
| useful when trying to salvage data from a corrupted repository. |
| |
| `GIT_ALLOW_PROTOCOL`:: |
| If set to a colon-separated list of protocols, behave as if |
| `protocol.allow` is set to `never`, and each of the listed |
| protocols has `protocol.<name>.allow` set to `always` |
| (overriding any existing configuration). See the description of |
| `protocol.allow` in linkgit:git-config[1] for more details. |
| |
| `GIT_PROTOCOL_FROM_USER`:: |
| Set to 0 to prevent protocols used by fetch/push/clone which are |
| configured to the `user` state. This is useful to restrict recursive |
| submodule initialization from an untrusted repository or for programs |
| which feed potentially-untrusted URLS to git commands. See |
| linkgit:git-config[1] for more details. |
| |
| `GIT_PROTOCOL`:: |
| For internal use only. Used in handshaking the wire protocol. |
| Contains a colon ':' separated list of keys with optional values |
| 'key[=value]'. Presence of unknown keys and values must be |
| ignored. |
| + |
| Note that servers may need to be configured to allow this variable to |
| pass over some transports. It will be propagated automatically when |
| accessing local repositories (i.e., `file://` or a filesystem path), as |
| well as over the `git://` protocol. For git-over-http, it should work |
| automatically in most configurations, but see the discussion in |
| linkgit:git-http-backend[1]. For git-over-ssh, the ssh server may need |
| to be configured to allow clients to pass this variable (e.g., by using |
| `AcceptEnv GIT_PROTOCOL` with OpenSSH). |
| + |
| This configuration is optional. If the variable is not propagated, then |
| clients will fall back to the original "v0" protocol (but may miss out |
| on some performance improvements or features). This variable currently |
| only affects clones and fetches; it is not yet used for pushes (but may |
| be in the future). |
| |
| `GIT_OPTIONAL_LOCKS`:: |
| If set to `0`, Git will complete any requested operation without |
| performing any optional sub-operations that require taking a lock. |
| For example, this will prevent `git status` from refreshing the |
| index as a side effect. This is useful for processes running in |
| the background which do not want to cause lock contention with |
| other operations on the repository. Defaults to `1`. |
| |
| `GIT_REDIRECT_STDIN`:: |
| `GIT_REDIRECT_STDOUT`:: |
| `GIT_REDIRECT_STDERR`:: |
| Windows-only: allow redirecting the standard input/output/error |
| handles to paths specified by the environment variables. This is |
| particularly useful in multi-threaded applications where the |
| canonical way to pass standard handles via `CreateProcess()` is |
| not an option because it would require the handles to be marked |
| inheritable (and consequently *every* spawned process would |
| inherit them, possibly blocking regular Git operations). The |
| primary intended use case is to use named pipes for communication |
| (e.g. `\\.\pipe\my-git-stdin-123`). |
| + |
| Two special values are supported: `off` will simply close the |
| corresponding standard handle, and if `GIT_REDIRECT_STDERR` is |
| `2>&1`, standard error will be redirected to the same handle as |
| standard output. |
| |
| `GIT_PRINT_SHA1_ELLIPSIS` (deprecated):: |
| If set to `yes`, print an ellipsis following an |
| (abbreviated) SHA-1 value. This affects indications of |
| detached HEADs (linkgit:git-checkout[1]) and the raw |
| diff output (linkgit:git-diff[1]). Printing an |
| ellipsis in the cases mentioned is no longer considered |
| adequate and support for it is likely to be removed in the |
| foreseeable future (along with the variable). |
| |
| Discussion[[Discussion]] |
| ------------------------ |
| |
| More detail on the following is available from the |
| link:user-manual.html#git-concepts[Git concepts chapter of the |
| user-manual] and linkgit:gitcore-tutorial[7]. |
| |
| A Git project normally consists of a working directory with a ".git" |
| subdirectory at the top level. The .git directory contains, among other |
| things, a compressed object database representing the complete history |
| of the project, an "index" file which links that history to the current |
| contents of the working tree, and named pointers into that history such |
| as tags and branch heads. |
| |
| The object database contains objects of three main types: blobs, which |
| hold file data; trees, which point to blobs and other trees to build up |
| directory hierarchies; and commits, which each reference a single tree |
| and some number of parent commits. |
| |
| The commit, equivalent to what other systems call a "changeset" or |
| "version", represents a step in the project's history, and each parent |
| represents an immediately preceding step. Commits with more than one |
| parent represent merges of independent lines of development. |
| |
| All objects are named by the SHA-1 hash of their contents, normally |
| written as a string of 40 hex digits. Such names are globally unique. |
| The entire history leading up to a commit can be vouched for by signing |
| just that commit. A fourth object type, the tag, is provided for this |
| purpose. |
| |
| When first created, objects are stored in individual files, but for |
| efficiency may later be compressed together into "pack files". |
| |
| Named pointers called refs mark interesting points in history. A ref |
| may contain the SHA-1 name of an object or the name of another ref. Refs |
| with names beginning `ref/head/` contain the SHA-1 name of the most |
| recent commit (or "head") of a branch under development. SHA-1 names of |
| tags of interest are stored under `ref/tags/`. A special ref named |
| `HEAD` contains the name of the currently checked-out branch. |
| |
| The index file is initialized with a list of all paths and, for each |
| path, a blob object and a set of attributes. The blob object represents |
| the contents of the file as of the head of the current branch. The |
| attributes (last modified time, size, etc.) are taken from the |
| corresponding file in the working tree. Subsequent changes to the |
| working tree can be found by comparing these attributes. The index may |
| be updated with new content, and new commits may be created from the |
| content stored in the index. |
| |
| The index is also capable of storing multiple entries (called "stages") |
| for a given pathname. These stages are used to hold the various |
| unmerged version of a file when a merge is in progress. |
| |
| FURTHER DOCUMENTATION |
| --------------------- |
| |
| See the references in the "description" section to get started |
| using Git. The following is probably more detail than necessary |
| for a first-time user. |
| |
| The link:user-manual.html#git-concepts[Git concepts chapter of the |
| user-manual] and linkgit:gitcore-tutorial[7] both provide |
| introductions to the underlying Git architecture. |
| |
| See linkgit:gitworkflows[7] for an overview of recommended workflows. |
| |
| See also the link:howto-index.html[howto] documents for some useful |
| examples. |
| |
| The internals are documented in the |
| link:technical/api-index.html[Git API documentation]. |
| |
| Users migrating from CVS may also want to |
| read linkgit:gitcvs-migration[7]. |
| |
| |
| Authors |
| ------- |
| Git was started by Linus Torvalds, and is currently maintained by Junio |
| C Hamano. Numerous contributions have come from the Git mailing list |
| <git@vger.kernel.org>. http://www.openhub.net/p/git/contributors/summary |
| gives you a more complete list of contributors. |
| |
| If you have a clone of git.git itself, the |
| output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you |
| the authors for specific parts of the project. |
| |
| Reporting Bugs |
| -------------- |
| |
| Report bugs to the Git mailing list <git@vger.kernel.org> where the |
| development and maintenance is primarily done. You do not have to be |
| subscribed to the list to send a message there. See the list archive |
| at https://lore.kernel.org/git for previous bug reports and other |
| discussions. |
| |
| Issues which are security relevant should be disclosed privately to |
| the Git Security mailing list <git-security@googlegroups.com>. |
| |
| SEE ALSO |
| -------- |
| linkgit:gittutorial[7], linkgit:gittutorial-2[7], |
| linkgit:giteveryday[7], linkgit:gitcvs-migration[7], |
| linkgit:gitglossary[7], linkgit:gitcore-tutorial[7], |
| linkgit:gitcli[7], link:user-manual.html[The Git User's Manual], |
| linkgit:gitworkflows[7] |
| |
| GIT |
| --- |
| Part of the linkgit:git[1] suite |