Git User Manual

From b47d9c841ffcd228bc7f676414b2e7086beb1550 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 11 Mar 2024 15:41:17 -0700 Subject: Autogenerated HTML docs for v2.44.0-191-g945115 --- MyFirstContribution.html | 2 +- MyFirstObjectWalk.html | 2 +- RelNotes/2.45.0.txt | 4 + ReviewingGuidelines.html | 2 +- SubmittingPatches.html | 2 +- ToolsForGit.html | 2 +- config.txt | 28 +- everyday.html | 2 +- git-config.html | 2902 +++++++++++++------------- git-remote-helpers.html | 2 +- gitcli.html | 8 +- gitcli.txt | 3 - howto/coordinate-embargoed-releases.html | 2 +- howto/keep-canonical-history-correct.html | 4 +- howto/maintain-git.html | 4 +- howto/new-command.html | 4 +- howto/rebase-from-internal-branch.html | 4 +- howto/rebuild-from-update-hook.html | 4 +- howto/recover-corrupted-blob-object.html | 4 +- howto/recover-corrupted-object-harder.html | 4 +- howto/revert-a-faulty-merge.html | 4 +- howto/revert-branch-rebase.html | 4 +- howto/separating-topic-branches.html | 4 +- howto/setup-git-server-over-http.html | 4 +- howto/update-hook-example.html | 4 +- howto/use-git-daemon.html | 4 +- howto/using-merge-subtree.html | 4 +- howto/using-signed-tag-in-pull-request.html | 4 +- technical/api-error-handling.html | 2 +- technical/api-index.html | 2 +- technical/api-merge.html | 2 +- technical/api-parse-options.html | 2 +- technical/api-simple-ipc.html | 2 +- technical/api-trace2.html | 2 +- technical/bitmap-format.html | 2 +- technical/bundle-uri.html | 2 +- technical/hash-function-transition.html | 2 +- technical/long-running-process-protocol.html | 2 +- technical/multi-pack-index.html | 2 +- technical/pack-heuristics.html | 2 +- technical/parallel-checkout.html | 2 +- technical/partial-clone.html | 2 +- technical/racy-git.html | 2 +- technical/scalar.html | 2 +- technical/send-pack-pipeline.html | 2 +- technical/shallow.html | 2 +- technical/trivial-merge.html | 2 +- technical/unit-tests.html | 2 +- user-manual.html | 2 +- 49 files changed, 1529 insertions(+), 1534 deletions(-) diff --git a/MyFirstContribution.html b/MyFirstContribution.html index 4fb5a5a19..5d5794304 100644 --- a/MyFirstContribution.html +++ b/MyFirstContribution.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/MyFirstObjectWalk.html b/MyFirstObjectWalk.html index d4d9e8e1c..369da93b0 100644 --- a/MyFirstObjectWalk.html +++ b/MyFirstObjectWalk.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/RelNotes/2.45.0.txt b/RelNotes/2.45.0.txt index c0f9b9e44..2e7593253 100644 --- a/RelNotes/2.45.0.txt +++ b/RelNotes/2.45.0.txt @@ -127,6 +127,9 @@ Fixes since v2.44 not advertise the capability, which has been corrected. (merge a922bfa3b5 jk/upload-pack-v2-capability-cleanup later to maint). + * Make sure failure return from merge_bases_many() is properly caught. + (merge 25fd20eb44 js/merge-base-with-missing-commit later to maint). + * Other code cleanup, docfix, build fix, etc. (merge f0e578c69c rs/use-xstrncmpz later to maint). (merge 83e6eb7d7a ba/credential-test-clean-fix later to maint). @@ -142,3 +145,4 @@ Fixes since v2.44 (merge 9a97b43e03 rs/submodule-prefix-simplify later to maint). (merge 40b8076462 ak/rebase-autosquash later to maint). (merge 3223204456 eg/add-uflags later to maint). + (merge 5f78d52dce es/config-doc-sort-sections later to maint). diff --git a/ReviewingGuidelines.html b/ReviewingGuidelines.html index 4aa5d90ea..e6a0ece11 100644 --- a/ReviewingGuidelines.html +++ b/ReviewingGuidelines.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/SubmittingPatches.html b/SubmittingPatches.html index 3a50e9980..4e68aee89 100644 --- a/SubmittingPatches.html +++ b/SubmittingPatches.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/ToolsForGit.html b/ToolsForGit.html index 453d24359..46f659fd2 100644 --- a/ToolsForGit.html +++ b/ToolsForGit.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/config.txt b/config.txt index e3a74dd1c..782c2bab9 100644 --- a/config.txt +++ b/config.txt @@ -369,20 +369,18 @@ inventing new variables for use in your own tool, make sure their names do not conflict with those that are used by Git itself and other popular tools, and describe them in your documentation. -include::config/advice.txt[] - -include::config/attr.txt[] - -include::config/core.txt[] - include::config/add.txt[] +include::config/advice.txt[] + include::config/alias.txt[] include::config/am.txt[] include::config/apply.txt[] +include::config/attr.txt[] + include::config/blame.txt[] include::config/branch.txt[] @@ -405,10 +403,12 @@ include::config/commit.txt[] include::config/commitgraph.txt[] -include::config/credential.txt[] - include::config/completion.txt[] +include::config/core.txt[] + +include::config/credential.txt[] + include::config/diff.txt[] include::config/difftool.txt[] @@ -421,10 +421,10 @@ include::config/feature.txt[] include::config/fetch.txt[] -include::config/format.txt[] - include::config/filter.txt[] +include::config/format.txt[] + include::config/fsck.txt[] include::config/fsmonitor--daemon.txt[] @@ -435,10 +435,10 @@ include::config/gitcvs.txt[] include::config/gitweb.txt[] -include::config/grep.txt[] - include::config/gpg.txt[] +include::config/grep.txt[] + include::config/gui.txt[] include::config/guitool.txt[] @@ -519,10 +519,10 @@ include::config/splitindex.txt[] include::config/ssh.txt[] -include::config/status.txt[] - include::config/stash.txt[] +include::config/status.txt[] + include::config/submodule.txt[] include::config/tag.txt[] diff --git a/everyday.html b/everyday.html index b6b536598..c931df498 100644 --- a/everyday.html +++ b/everyday.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/git-config.html b/git-config.html index 7b99b74d6..1a2dc4c6c 100644 --- a/git-config.html +++ b/git-config.html @@ -1979,6 +1979,32 @@ names do not conflict with those that are used by Git itself and other popular tools, and describe them in your documentation.

+add.ignoreErrors +
+add.ignore-errors (deprecated) +: +
+ Tells git add to continue adding files when some files cannot be + added due to indexing errors. Equivalent to the --ignore-errors + option of git-add(1). add.ignore-errors is deprecated, + as it does not follow the usual naming convention for configuration + variables. +
+
+add.interactive.useBuiltin +: +
+ Unused configuration variable. Used in Git versions v2.25.0 to + v2.36.0 to enable the built-in version of git-add(1)'s + interactive mode, which then became the default in Git + versions v2.37.0 to v2.39.0. +
+
advice.*: @@ -2361,2238 +2387,2225 @@ worktreeAddOrphan

-attr.tree +alias.*

- A reference to a tree in the repository from which to read attributes, - instead of the .gitattributes file in the working tree. In a bare - repository, this defaults to HEAD:.gitattributes. If the value does - not resolve to a valid tree object, an empty tree is used instead. - When the GIT_ATTR_SOURCE environment variable or --attr-source - command line option are used, this configuration variable has no effect. + Command aliases for the git(1) command wrapper - e.g. + after defining alias.last = cat-file commit HEAD, the invocation + git last is equivalent to git cat-file commit HEAD. To avoid + confusion and troubles with script usage, aliases that + hide existing Git commands are ignored. Arguments are split by + spaces, the usual shell quoting and escaping are supported. + A quote pair or a backslash can be used to quote them.

Note that the first word of an alias does not necessarily have to be a +command. It can be a command-line option that will be passed into the +invocation of git. In particular, this is useful when used with -c +to pass in one-time configurations or -p to force pagination. For example, +loud-rebase = -c commit.verbose=true rebase can be defined such that +running git loud-rebase would be equivalent to +git -c commit.verbose=true rebase. Also, ps = -p status would be a +helpful alias since git ps would paginate the output of git status +where the original command does not.

If the alias expansion is prefixed with an exclamation point, +it will be treated as a shell command. For example, defining +alias.new = !gitk --all --not ORIG_HEAD, the invocation +git new is equivalent to running the shell command +gitk --all --not ORIG_HEAD. Note that shell commands will be +executed from the top-level directory of a repository, which may +not necessarily be the current directory. +GIT_PREFIX is set as returned by running git rev-parse --show-prefix +from the original current directory. See git-rev-parse(1).

-core.fileMode +am.keepcr

- Tells Git if the executable bit of files in the working tree - is to be honored. + If true, git-am will call git-mailsplit for patches in mbox format + with parameter --keep-cr. In this case git-mailsplit will + not remove \r from lines ending with \r\n. Can be overridden + by giving --no-keep-cr from the command line. + See git-am(1), git-mailsplit(1).

Some filesystems lose the executable bit when a file that is -marked as executable is checked out, or checks out a -non-executable file with executable bit on. -git-clone(1) or git-init(1) probe the filesystem -to see if it handles the executable bit correctly -and this variable is automatically set as necessary.

A repository, however, may be on a filesystem that handles -the filemode correctly, and this variable is set to true -when created, but later may be made accessible from another -environment that loses the filemode (e.g. exporting ext4 via -CIFS mount, visiting a Cygwin created repository with -Git for Windows or Eclipse). -In such a case it may be necessary to set this variable to false. -See git-update-index(1).

The default is true (when core.filemode is not specified in the config file).

-core.hideDotFiles +am.threeWay

- (Windows-only) If true, mark newly-created directories and files whose - name starts with a dot as hidden. If dotGitOnly, only the .git/ - directory is hidden, but no other files starting with a dot. The - default mode is dotGitOnly. + By default, git am will fail if the patch does not apply cleanly. When + set to true, this setting tells git am to fall back on 3-way merge if + the patch records the identity of blobs it is supposed to apply to and + we have those blobs available locally (equivalent to giving the --3way + option from the command line). Defaults to false. + See git-am(1).

-core.ignoreCase +apply.ignoreWhitespace

- Internal variable which enables various workarounds to enable - Git to work better on filesystems that are not case sensitive, - like APFS, HFS+, FAT, NTFS, etc. For example, if a directory listing - finds "makefile" when Git expects "Makefile", Git will assume - it is really the same file, and continue to remember it as - "Makefile". + When set to change, tells git apply to ignore changes in + whitespace, in the same way as the --ignore-space-change + option. + When set to one of: no, none, never, false, it tells git apply to + respect all whitespace differences. + See git-apply(1).

The default is false, except git-clone(1) or git-init(1) -will probe and set core.ignoreCase true if appropriate when the repository -is created.

Git relies on the proper configuration of this variable for your operating -and file system. Modifying this value may result in unexpected behavior.

-core.precomposeUnicode +apply.whitespace

- This option is only used by Mac OS implementation of Git. - When core.precomposeUnicode=true, Git reverts the unicode decomposition - of filenames done by Mac OS. This is useful when sharing a repository - between Mac OS and Linux or Windows. - (Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7). - When false, file names are handled fully transparent by Git, - which is backward compatible with older versions of Git. + Tells git apply how to handle whitespace, in the same way + as the --whitespace option. See git-apply(1).

-core.protectHFS +attr.tree

- If set to true, do not allow checkout of paths that would - be considered equivalent to .git on an HFS+ filesystem. - Defaults to true on Mac OS, and false elsewhere. + A reference to a tree in the repository from which to read attributes, + instead of the .gitattributes file in the working tree. In a bare + repository, this defaults to HEAD:.gitattributes. If the value does + not resolve to a valid tree object, an empty tree is used instead. + When the GIT_ATTR_SOURCE environment variable or --attr-source + command line option are used, this configuration variable has no effect.

-core.protectNTFS +blame.blankBoundary

- If set to true, do not allow checkout of paths that would - cause problems with the NTFS filesystem, e.g. conflict with - 8.3 "short" names. - Defaults to true on Windows, and false elsewhere. + Show blank commit object name for boundary commits in + git-blame(1). This option defaults to false.

-core.fsmonitor +blame.coloring

- If set to true, enable the built-in file system monitor - daemon for this working directory (git-fsmonitor--daemon(1)). + This determines the coloring scheme to be applied to blame + output. It can be repeatedLines, highlightRecent, + or none which is the default.

Like hook-based file system monitors, the built-in file system monitor -can speed up Git commands that need to refresh the Git index -(e.g. git status) in a working directory with many files. The -built-in monitor eliminates the need to install and maintain an -external third-party tool.

The built-in file system monitor is currently available only on a -limited set of supported platforms. Currently, this includes Windows -and MacOS.

Otherwise, this variable contains the pathname of the "fsmonitor"
-hook command.

This hook command is used to identify all files that may have changed -since the requested date/time. This information is used to speed up -git by avoiding unnecessary scanning of files that have not changed.

See the "fsmonitor-watchman" section of githooks(5).

Note that if you concurrently use multiple versions of Git, such -as one version on the command line and another version in an IDE -tool, that the definition of core.fsmonitor was extended to -allow boolean values in addition to hook pathnames. Git versions -2.35.1 and prior will not understand the boolean values and will -consider the "true" or "false" values as hook pathnames to be -invoked. Git versions 2.26 thru 2.35.1 default to hook protocol -V2 and will fall back to no fsmonitor (full scan). Git versions -prior to 2.26 default to hook protocol V1 and will silently -assume there were no changes to report (no scan), so status -commands may report incomplete results. For this reason, it is -best to upgrade all of your Git versions before using the built-in -file system monitor.

-core.fsmonitorHookVersion +blame.date

- Sets the protocol version to be used when invoking the - "fsmonitor" hook. + Specifies the format used to output dates in git-blame(1). + If unset the iso format is used. For supported values, + see the discussion of the --date option at git-log(1).

There are currently versions 1 and 2. When this is not set, -version 2 will be tried first and if it fails then version 1 -will be tried. Version 1 uses a timestamp as input to determine -which files have changes since that time but some monitors -like Watchman have race conditions when used with a timestamp. -Version 2 uses an opaque string so that the monitor can return -something that can be used to determine what files have changed -without race conditions.

-core.trustctime +blame.showEmail

- If false, the ctime differences between the index and the - working tree are ignored; useful when the inode change time - is regularly modified by something outside Git (file system - crawlers and some backup systems). - See git-update-index(1). True by default. + Show the author email instead of author name in git-blame(1). + This option defaults to false.

-core.splitIndex +blame.showRoot

- If true, the split-index feature of the index will be used. - See git-update-index(1). False by default. + Do not treat root commits as boundaries in git-blame(1). + This option defaults to false.

-core.untrackedCache +blame.ignoreRevsFile

- Determines what to do about the untracked cache feature of the - index. It will be kept, if this variable is unset or set to - keep. It will automatically be added if set to true. And - it will automatically be removed, if set to false. Before - setting it to true, you should check that mtime is working - properly on your system. - See git-update-index(1). keep by default, unless - feature.manyFiles is enabled which sets this setting to - true by default. + Ignore revisions listed in the file, one unabbreviated object name per + line, in git-blame(1). Whitespace and comments beginning with + # are ignored. This option may be repeated multiple times. Empty + file names will reset the list of ignored revisions. This option will + be handled before the command line option --ignore-revs-file.

-core.checkStat +blame.markUnblamableLines

- When missing or is set to default, many fields in the stat - structure are checked to detect if a file has been modified - since Git looked at it. When this configuration variable is - set to minimal, sub-second part of mtime and ctime, the - uid and gid of the owner of the file, the inode number (and - the device number, if Git was compiled to use it), are - excluded from the check among these fields, leaving only the - whole-second part of mtime (and ctime, if core.trustCtime - is set) and the filesize to be checked. + Mark lines that were changed by an ignored revision that we could not + attribute to another commit with a * in the output of + git-blame(1).

There are implementations of Git that do not leave usable values in -some fields (e.g. JGit); by excluding these fields from the -comparison, the minimal mode may help interoperability when the -same repository is used by these other systems at the same time.

-core.quotePath +blame.markIgnoredLines

- Commands that output paths (e.g. ls-files, diff), will - quote "unusual" characters in the pathname by enclosing the - pathname in double-quotes and escaping those characters with - backslashes in the same way C escapes control characters (e.g. - \t for TAB, \n for LF, \\ for backslash) or bytes with - values larger than 0x80 (e.g. octal \302\265 for "micro" in - UTF-8). If this variable is set to false, bytes higher than - 0x80 are not considered "unusual" any more. Double-quotes, - backslash and control characters are always escaped regardless - of the setting of this variable. A simple space character is - not considered "unusual". Many commands can output pathnames - completely verbatim using the -z option. The default value - is true. + Mark lines that were changed by an ignored revision that we attributed to + another commit with a ? in the output of git-blame(1).

-core.eol +branch.autoSetupMerge

- Sets the line ending type to use in the working directory for - files that are marked as text (either by having the text - attribute set, or by having text=auto and Git auto-detecting - the contents as text). - Alternatives are lf, crlf and native, which uses the platform’s - native line ending. The default value is native. See - gitattributes(5) for more information on end-of-line - conversion. Note that this value is ignored if core.autocrlf - is set to true or input. + Tells git branch, git switch and git checkout to set up new branches + so that git-pull(1) will appropriately merge from the + starting point branch. Note that even if this option is not set, + this behavior can be chosen per-branch using the --track + and --no-track options. The valid settings are: false — no + automatic setup is done; true — automatic setup is done when the + starting point is a remote-tracking branch; always — automatic setup is done when the starting point is either a + local branch or remote-tracking branch; inherit — if the starting point + has a tracking configuration, it is copied to the new + branch; simple — automatic setup is done only when the starting point + is a remote-tracking branch and the new branch has the same name as the + remote branch. This option defaults to true.

-core.safecrlf +branch.autoSetupRebase

- If true, makes Git check if converting CRLF is reversible when - end-of-line conversion is active. Git will verify if a command - modifies a file in the work tree either directly or indirectly. - For example, committing a file followed by checking out the - same file should yield the original file in the work tree. If - this is not the case for the current setting of - core.autocrlf, Git will reject the file. The variable can - be set to "warn", in which case Git will only warn about an - irreversible conversion but continue the operation. + When a new branch is created with git branch, git switch or git checkout + that tracks another branch, this variable tells Git to set + up pull to rebase instead of merge (see "branch.<name>.rebase"). + When never, rebase is never automatically set to true. + When local, rebase is set to true for tracked branches of + other local branches. + When remote, rebase is set to true for tracked branches of + remote-tracking branches. + When always, rebase will be set to true for all tracking + branches. + See "branch.autoSetupMerge" for details on how to set up a + branch to track another branch. + This option defaults to never.

CRLF conversion bears a slight chance of corrupting data. -When it is enabled, Git will convert CRLF to LF during commit and LF to -CRLF during checkout. A file that contains a mixture of LF and -CRLF before the commit cannot be recreated by Git. For text -files this is the right thing to do: it corrects line endings -such that we have only LF line endings in the repository. -But for binary files that are accidentally classified as text the -conversion can corrupt data.

If you recognize such corruption early you can easily fix it by -setting the conversion type explicitly in .gitattributes. Right -after committing you still have the original file in your work -tree and this file is not yet corrupted. You can explicitly tell -Git that this file is binary and Git will handle the file -appropriately.

Unfortunately, the desired effect of cleaning up text files with -mixed line endings and the undesired effect of corrupting binary -files cannot be distinguished. In both cases CRLFs are removed -in an irreversible way. For text files this is the right thing -to do because CRLFs are line endings, while for binary files -converting CRLFs corrupts data.

Note, this safety check does not mean that a checkout will generate a -file identical to the original file for a different setting of -core.eol and core.autocrlf, but only for the current one. For -example, a text file with LF would be accepted with core.eol=lf -and could later be checked out with core.eol=crlf, in which case the -resulting file would contain CRLF, although the original file -contained LF. However, in both work trees the line endings would be -consistent, that is either all LF or all CRLF, but never mixed. A -file with mixed line endings would be reported by the core.safecrlf -mechanism.

-core.autocrlf +branch.sort

- Setting this variable to "true" is the same as setting - the text attribute to "auto" on all files and core.eol to "crlf". - Set to true if you want to have CRLF line endings in your - working directory and the repository has LF line endings. - This variable can be set to input, - in which case no output conversion is performed. + This variable controls the sort ordering of branches when displayed by + git-branch(1). Without the "--sort=<value>" option provided, the + value of this variable will be used as the default. + See git-for-each-ref(1) field names for valid values.

-core.checkRoundtripEncoding +branch.<name>.remote

- A comma and/or whitespace separated list of encodings that Git - performs UTF-8 round trip checks on if they are used in an - working-tree-encoding attribute (see gitattributes(5)). - The default value is SHIFT-JIS. + When on branch <name>, it tells git fetch and git push + which remote to fetch from or push to. The remote to push to + may be overridden with remote.pushDefault (for all branches). + The remote to push to, for the current branch, may be further + overridden by branch.<name>.pushRemote. If no remote is + configured, or if you are not on any branch and there is more than + one remote defined in the repository, it defaults to origin for + fetching and remote.pushDefault for pushing. + Additionally, . (a period) is the current local repository + (a dot-repository), see branch.<name>.merge's final note below.

-core.symlinks +branch.<name>.pushRemote

- If false, symbolic links are checked out as small plain files that - contain the link text. git-update-index(1) and - git-add(1) will not change the recorded type to regular - file. Useful on filesystems like FAT that do not support - symbolic links. + When on branch <name>, it overrides branch.<name>.remote for + pushing. It also overrides remote.pushDefault for pushing + from branch <name>. When you pull from one place (e.g. your + upstream) and push to another place (e.g. your own publishing + repository), you would want to set remote.pushDefault to + specify the remote to push to for all branches, and use this + option to override it for a specific branch.

The default is true, except git-clone(1) or git-init(1) -will probe and set core.symlinks false if appropriate when the repository -is created.

-core.gitProxy +branch.<name>.merge

- A "proxy command" to execute (as command host port) instead - of establishing direct connection to the remote server when - using the Git protocol for fetching. If the variable value is - in the "COMMAND for DOMAIN" format, the command is applied only - on hostnames ending with the specified domain string. This variable - may be set multiple times and is matched in the given order; - the first match wins. + Defines, together with branch.<name>.remote, the upstream branch + for the given branch. It tells git fetch/git pull/git rebase which + branch to merge and can also affect git push (see push.default). + When in branch <name>, it tells git fetch the default + refspec to be marked for merging in FETCH_HEAD. The value is + handled like the remote part of a refspec, and must match a + ref which is fetched from the remote given by + "branch.<name>.remote". + The merge information is used by git pull (which first calls + git fetch) to lookup the default branch for merging. Without + this option, git pull defaults to merge the first refspec fetched. + Specify multiple values to get an octopus merge. + If you wish to setup git pull so that it merges into <name> from + another branch in the local repository, you can point + branch.<name>.merge to the desired branch, and use the relative path + setting . (a period) for branch.<name>.remote.

Can be overridden by the GIT_PROXY_COMMAND environment variable -(which always applies universally, without the special "for" -handling).

The special string none can be used as the proxy command to -specify that no proxy be used for a given domain pattern. -This is useful for excluding servers inside a firewall from -proxy use, while defaulting to a common proxy for external domains.

-core.sshCommand +branch.<name>.mergeOptions

- If this variable is set, git fetch and git push will - use the specified command instead of ssh when they need to - connect to a remote system. The command is in the same form as - the GIT_SSH_COMMAND environment variable and is overridden - when the environment variable is set. + Sets default options for merging into branch <name>. The syntax and + supported options are the same as those of git-merge(1), but + option values containing whitespace characters are currently not + supported.

-core.ignoreStat +branch.<name>.rebase

- If true, Git will avoid using lstat() calls to detect if files have - changed by setting the "assume-unchanged" bit for those tracked files - which it has updated identically in both the index and working tree. + When true, rebase the branch <name> on top of the fetched branch, + instead of merging the default branch from the default remote when + "git pull" is run. See "pull.rebase" for doing this in a non + branch-specific manner.

When files are modified outside of Git, the user will need to stage -the modified files explicitly (e.g. see Examples section in -git-update-index(1)). -Git will not normally detect changes to those files.

This is useful on systems where lstat() calls are very slow, such as -CIFS/Microsoft Windows.

False by default.

When merges (or just m), pass the --rebase-merges option to git rebase +so that the local merge commits are included in the rebase (see +git-rebase(1) for details).

When the value is interactive (or just i), the rebase is run in interactive +mode.

NOTE: this is a possibly dangerous operation; do not use +it unless you understand the implications (see git-rebase(1) +for details).

-core.preferSymlinkRefs +branch.<name>.description

- Instead of the default "symref" format for HEAD - and other symbolic reference files, use symbolic links. - This is sometimes needed to work with old scripts that - expect HEAD to be a symbolic link. + Branch description, can be edited with + git branch --edit-description. Branch description is + automatically added to the format-patch cover letter or + request-pull summary.

-core.alternateRefsCommand +browser.<tool>.cmd

- When advertising tips of available history from an alternate, use the shell to - execute the specified command instead of git-for-each-ref(1). The - first argument is the absolute path of the alternate. Output must contain one - hex object id per line (i.e., the same as produced by git for-each-ref - --format='%(objectname)'). + Specify the command to invoke the specified browser. The + specified command is evaluated in shell with the URLs passed + as arguments. (See git-web--browse(1).)

Note that you cannot generally put git for-each-ref directly into the config -value, as it does not take a repository path as an argument (but you can wrap -the command above in a shell script).

-core.alternateRefsPrefixes +browser.<tool>.path

- When listing references from an alternate, list only references that begin - with the given prefix. Prefixes match as if they were given as arguments to - git-for-each-ref(1). To list multiple prefixes, separate them with - whitespace. If core.alternateRefsCommand is set, setting - core.alternateRefsPrefixes has no effect. + Override the path for the given tool that may be used to + browse HTML help (see -w option in git-help(1)) or a + working repository in gitweb (see git-instaweb(1)).

-core.bare +bundle.*

- If true this repository is assumed to be bare and has no - working directory associated with it. If this is the case a - number of commands that require a working directory will be - disabled, such as git-add(1) or git-merge(1). + The bundle.* keys may appear in a bundle list file found via the + git clone --bundle-uri option. These keys currently have no effect + if placed in a repository config file, though this will change in the + future. See the bundle URI design + document for more details.

This setting is automatically guessed by git-clone(1) or -git-init(1) when the repository was created. By default a -repository that ends in "/.git" is assumed to be not bare (bare = -false), while all other repositories are assumed to be bare (bare -= true).

-core.worktree +bundle.version

- Set the path to the root of the working tree. - If GIT_COMMON_DIR environment variable is set, core.worktree - is ignored and not used for determining the root of working tree. - This can be overridden by the GIT_WORK_TREE environment - variable and the --work-tree command-line option. - The value can be an absolute path or relative to the path to - the .git directory, which is either specified by --git-dir - or GIT_DIR, or automatically discovered. - If --git-dir or GIT_DIR is specified but none of - --work-tree, GIT_WORK_TREE and core.worktree is specified, - the current working directory is regarded as the top level - of your working tree. + This integer value advertises the version of the bundle list format + used by the bundle list. Currently, the only accepted value is 1.

Note that this variable is honored even when set in a configuration -file in a ".git" subdirectory of a directory and its value differs -from the latter directory (e.g. "/path/to/.git/config" has -core.worktree set to "/different/path"), which is most likely a -misconfiguration. Running Git commands in the "/path/to" directory will -still use "/different/path" as the root of the work tree and can cause -confusion unless you know what you are doing (e.g. you are creating a -read-only snapshot of the same index to a location different from the -repository’s usual working tree).

-core.logAllRefUpdates +bundle.mode

- Enable the reflog. Updates to a ref <ref> is logged to the file - "$GIT_DIR/logs/<ref>", by appending the new and old - SHA-1, the date/time and the reason of the update, but - only when the file exists. If this configuration - variable is set to true, missing "$GIT_DIR/logs/<ref>" - file is automatically created for branch heads (i.e. under - refs/heads/), remote refs (i.e. under refs/remotes/), - note refs (i.e. under refs/notes/), and the symbolic ref HEAD. - If it is set to always, then a missing reflog is automatically - created for any ref under refs/. + This string value should be either all or any. This value describes + whether all of the advertised bundles are required to unbundle a + complete understanding of the bundled information (all) or if any one + of the listed bundle URIs is sufficient (any).

This information can be used to determine what commit -was the tip of a branch "2 days ago".

This value is true by default in a repository that has -a working directory associated with it, and false by -default in a bare repository.

-core.repositoryFormatVersion +bundle.heuristic

- Internal variable identifying the repository format and layout - version. + If this string-valued key exists, then the bundle list is designed to + work well with incremental git fetch commands. The heuristic signals + that there are additional keys available for each bundle that help + determine which subset of bundles the client should download. The + only value currently understood is creationToken.

-core.sharedRepository +bundle.<id>.*

- When group (or true), the repository is made shareable between - several users in a group (making sure all the files and objects are - group-writable). When all (or world or everybody), the - repository will be readable by all users, additionally to being - group-shareable. When umask (or false), Git will use permissions - reported by umask(2). When 0xxx, where 0xxx is an octal number, - files in the repository will have this mode value. 0xxx will override - user’s umask value (whereas the other options will only override - requested parts of the user’s umask value). Examples: 0660 will make - the repo read/write-able for the owner and group, but inaccessible to - others (equivalent to group unless umask is e.g. 0022). 0640 is a - repository that is group-readable but not group-writable. - See git-init(1). False by default. + The bundle.<id>.* keys are used to describe a single item in the + bundle list, grouped under <id> for identification purposes.

-core.warnAmbiguousRefs +bundle.<id>.uri

- If true, Git will warn you if the ref name you passed it is ambiguous - and might match multiple refs in the repository. True by default. + This string value defines the URI by which Git can reach the contents + of this <id>. This URI may be a bundle file or another bundle list.

-core.compression +checkout.defaultRemote

- An integer -1..9, indicating a default compression level. - -1 is the zlib default. 0 means no compression, - and 1..9 are various speed/size tradeoffs, 9 being slowest. - If set, this provides a default to other compression variables, - such as core.looseCompression and pack.compression. + When you run git checkout <something> + or git switch <something> and only have one + remote, it may implicitly fall back on checking out and + tracking e.g. origin/<something>. This stops working as soon + as you have more than one remote with a <something> + reference. This setting allows for setting the name of a + preferred remote that should always win when it comes to + disambiguation. The typical use-case is to set this to + origin.

Currently this is used by git-switch(1) and +git-checkout(1) when git checkout <something> +or git switch <something> +will checkout the <something> branch on another remote, +and by git-worktree(1) when git worktree add refers to a +remote branch. This setting might be used for other checkout-like +commands or functionality in the future.

-core.looseCompression +checkout.guess

- An integer -1..9, indicating the compression level for objects that - are not in a pack file. -1 is the zlib default. 0 means no - compression, and 1..9 are various speed/size tradeoffs, 9 being - slowest. If not set, defaults to core.compression. If that is - not set, defaults to 1 (best speed). + Provides the default value for the --guess or --no-guess + option in git checkout and git switch. See + git-switch(1) and git-checkout(1).

-core.packedGitWindowSize +checkout.workers

- Number of bytes of a pack file to map into memory in a - single mapping operation. Larger window sizes may allow - your system to process a smaller number of large pack files - more quickly. Smaller window sizes will negatively affect - performance due to increased calls to the operating system’s - memory manager, but may improve performance when accessing - a large number of large pack files. + The number of parallel workers to use when updating the working tree. + The default is one, i.e. sequential execution. If set to a value less + than one, Git will use as many workers as the number of logical cores + available. This setting and checkout.thresholdForParallelism affect + all commands that perform checkout. E.g. checkout, clone, reset, + sparse-checkout, etc.

Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32 -MiB on 32 bit platforms and 1 GiB on 64 bit platforms. This should -be reasonable for all users/operating systems. You probably do -not need to adjust this value.

Common unit suffixes of k, m, or g are supported.

Note: Parallel checkout usually delivers better performance for repositories +located on SSDs or over NFS. For repositories on spinning disks and/or machines +with a small number of cores, the default sequential checkout often performs +better. The size and compression level of a repository might also influence how +well the parallel version performs.

-core.packedGitLimit +checkout.thresholdForParallelism

- Maximum number of bytes to map simultaneously into memory - from pack files. If Git needs to access more than this many - bytes at once to complete an operation it will unmap existing - regions to reclaim virtual address space within the process. + When running parallel checkout with a small number of files, the cost + of subprocess spawning and inter-process communication might outweigh + the parallelization gains. This setting allows you to define the minimum + number of files for which parallel checkout should be attempted. The + default is 100.

Default is 256 MiB on 32 bit platforms and 32 TiB (effectively -unlimited) on 64 bit platforms. -This should be reasonable for all users/operating systems, except on -the largest projects. You probably do not need to adjust this value.

Common unit suffixes of k, m, or g are supported.

-core.deltaBaseCacheLimit +clean.requireForce

- Maximum number of bytes per thread to reserve for caching base objects - that may be referenced by multiple deltified objects. By storing the - entire decompressed base objects in a cache Git is able - to avoid unpacking and decompressing frequently used base - objects multiple times. + A boolean to make git-clean do nothing unless given -f, + -i, or -n. Defaults to true.

Default is 96 MiB on all platforms. This should be reasonable -for all users/operating systems, except on the largest projects. -You probably do not need to adjust this value.

Common unit suffixes of k, m, or g are supported.

-core.bigFileThreshold +clone.defaultRemoteName

- The size of files considered "big", which as discussed below - changes the behavior of numerous git commands, as well as how - such files are stored within the repository. The default is - 512 MiB. Common unit suffixes of k, m, or g are - supported. -

Files above the configured limit will be:

-
-Stored deflated in packfiles, without attempting delta compression. -
-
The default limit is primarily set with this use-case in mind. With it, -most projects will have their source code and other text files delta -compressed, but not larger binary media files.
-
Storing large files without delta compression avoids excessive memory -usage, at the slight expense of increased disk usage.
-
-
-Will be treated as if they were labeled "binary" (see - gitattributes(5)). e.g. git-log(1) and - git-diff(1) will not compute diffs for files above this limit. -
-
-
-Will generally be streamed when written, which avoids excessive -memory usage, at the cost of some fixed overhead. Commands that make -use of this include git-archive(1), -git-fast-import(1), git-index-pack(1), -git-unpack-objects(1) and git-fsck(1). + The name of the remote to create when cloning a repository. Defaults to + origin, and can be overridden by passing the --origin command-line + option to git-clone(1).
-

-core.excludesFile +clone.rejectShallow

- Specifies the pathname to the file that contains patterns to - describe paths that are not meant to be tracked, in addition - to .gitignore (per-directory) and .git/info/exclude. - Defaults to $XDG_CONFIG_HOME/git/ignore. - If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore - is used instead. See gitignore(5). + Reject cloning a repository if it is a shallow one; this can be overridden by + passing the --reject-shallow option on the command line. See git-clone(1)

-core.askPass +clone.filterSubmodules

- Some commands (e.g. svn and http interfaces) that interactively - ask for a password can be told to use an external program given - via the value of this variable. Can be overridden by the GIT_ASKPASS - environment variable. If not set, fall back to the value of the - SSH_ASKPASS environment variable or, failing that, a simple password - prompt. The external program shall be given a suitable prompt as - command-line argument and write the password on its STDOUT. + If a partial clone filter is provided (see --filter in + git-rev-list(1)) and --recurse-submodules is used, also apply + the filter to submodules.

-core.attributesFile +color.advice

- In addition to .gitattributes (per-directory) and - .git/info/attributes, Git looks into this file for attributes - (see gitattributes(5)). Path expansions are made the same - way as for core.excludesFile. Its default value is - $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME is either not - set or empty, $HOME/.config/git/attributes is used instead. + A boolean to enable/disable color in hints (e.g. when a push + failed, see advice.* for a list). May be set to always, + false (or never) or auto (or true), in which case colors + are used only when the error output goes to a terminal. If + unset, then the value of color.ui is used (auto by default).

-core.hooksPath +color.advice.hint

- By default Git will look for your hooks in the - $GIT_DIR/hooks directory. Set this to different path, - e.g. /etc/git/hooks, and Git will try to find your hooks in - that directory, e.g. /etc/git/hooks/pre-receive instead of - in $GIT_DIR/hooks/pre-receive. + Use customized color for hints.

The path can be either absolute or relative. A relative path is -taken as relative to the directory where the hooks are run (see -the "DESCRIPTION" section of githooks(5)).

This configuration variable is useful in cases where you’d like to -centrally configure your Git hooks instead of configuring them on a -per-repository basis, or as a more flexible and centralized -alternative to having an init.templateDir where you’ve changed -default hooks.

-core.editor +color.blame.highlightRecent

- Commands such as commit and tag that let you edit - messages by launching an editor use the value of this - variable when it is set, and the environment variable - GIT_EDITOR is not set. See git-var(1). + Specify the line annotation color for git blame --color-by-age + depending upon the age of the line.

This setting should be set to a comma-separated list of color and +date settings, starting and ending with a color, the dates should be +set from oldest to newest. The metadata will be colored with the +specified colors if the line was introduced before the given +timestamp, overwriting older timestamped colors.

Instead of an absolute timestamp relative timestamps work as well, +e.g. 2.weeks.ago is valid to address anything older than 2 weeks.

It defaults to blue,12 month ago,white,1 month ago,red, which +colors everything older than one year blue, recent changes between +one month and one year old are kept white, and lines introduced +within the last month are colored red.

-core.commentChar -

- Commands such as commit and tag that let you edit - messages consider a line that begins with this character - commented, and removes them after the editor returns - (default #). -

If set to "auto", git-commit would select a character that is not -the beginning character of any line in existing commit messages.

-core.filesRefLockTimeout +color.blame.repeatedLines

- The length of time, in milliseconds, to retry when trying to - lock an individual reference. Value 0 means not to retry at - all; -1 means to try indefinitely. Default is 100 (i.e., - retry for 100ms). + Use the specified color to colorize line annotations for + git blame --color-lines, if they come from the same commit as the + preceding line. Defaults to cyan.

-core.packedRefsTimeout +color.branch

- The length of time, in milliseconds, to retry when trying to - lock the packed-refs file. Value 0 means not to retry at - all; -1 means to try indefinitely. Default is 1000 (i.e., - retry for 1 second). + A boolean to enable/disable color in the output of + git-branch(1). May be set to always, + false (or never) or auto (or true), in which case colors are used + only when the output is to a terminal. If unset, then the + value of color.ui is used (auto by default).

-core.pager +color.branch.<slot>

- Text viewer for use by Git commands (e.g., less). The value - is meant to be interpreted by the shell. The order of preference - is the $GIT_PAGER environment variable, then core.pager - configuration, then $PAGER, and then the default chosen at - compile time (usually less). + Use customized color for branch coloration. <slot> is one of + current (the current branch), local (a local branch), + remote (a remote-tracking branch in refs/remotes/), + upstream (upstream tracking branch), plain (other + refs).

When the LESS environment variable is unset, Git sets it to FRX -(if LESS environment variable is set, Git does not change it at -all). If you want to selectively override Git’s default setting -for LESS, you can set core.pager to e.g. less -S. This will -be passed to the shell by Git, which will translate the final -command to LESS=FRX less -S. The environment does not set the -S option but the command line does, instructing less to truncate -long lines. Similarly, setting core.pager to less -+F will -deactivate the F option specified by the environment from the -command-line, deactivating the "quit if one screen" behavior of -less. One can specifically activate some flags for particular -commands: for example, setting pager.blame to less -S enables -line truncation only for git blame.

Likewise, when the LV environment variable is unset, Git sets it -to -c. You can override this setting by exporting LV with -another value or setting core.pager to lv +c.

-core.whitespace +color.diff

- A comma separated list of common whitespace problems to - notice. git diff will use color.diff.whitespace to - highlight them, and git apply --whitespace=error will - consider them as errors. You can prefix - to disable - any of them (e.g. -trailing-space): -

-
-blank-at-eol treats trailing whitespaces at the end of the line - as an error (enabled by default). -
-
-
-space-before-tab treats a space character that appears immediately - before a tab character in the initial indent part of the line as an - error (enabled by default). -
-
-
-indent-with-non-tab treats a line that is indented with space - characters instead of the equivalent tabs as an error (not enabled by - default). -
-
-
-tab-in-indent treats a tab character in the initial indent part of - the line as an error (not enabled by default). -
-
-
-blank-at-eof treats blank lines added at the end of file as an error - (enabled by default). -
-
-
-trailing-space is a short-hand to cover both blank-at-eol and - blank-at-eof. -
-
-
-cr-at-eol treats a carriage-return at the end of line as - part of the line terminator, i.e. with it, trailing-space - does not trigger if the character before such a carriage-return - is not a whitespace (not enabled by default). -
-
-
-tabwidth=<n> tells how many character positions a tab occupies; this - is relevant for indent-with-non-tab and when Git fixes tab-in-indent - errors. The default tab width is 8. Allowed values are 1 to 63. + Whether to use ANSI escape sequences to add color to patches. + If this is set to always, git-diff(1), + git-log(1), and git-show(1) will use color + for all patches. If it is set to true or auto, those + commands will only use color when output is to the terminal. + If unset, then the value of color.ui is used (auto by + default).
-

This does not affect git-format-patch(1) or the +git-diff-* plumbing commands. Can be overridden on the +command line with the --color[=<when>] option.

-core.fsync +color.diff.<slot>

- A comma-separated list of components of the repository that - should be hardened via the core.fsyncMethod when created or - modified. You can disable hardening of any component by - prefixing it with a -. Items that are not hardened may be - lost in the event of an unclean system shutdown. Unless you - have special requirements, it is recommended that you leave - this option empty or pick one of committed, added, - or all. -

When this configuration is encountered, the set of components starts with -the platform default value, disabled components are removed, and additional -components are added. none resets the state so that the platform default -is ignored.

The empty string resets the fsync configuration to the platform -default. The default on most platforms is equivalent to -core.fsync=committed,-loose-object, which has good performance, -but risks losing recent work in the event of an unclean system shutdown.

-
-none clears the set of fsynced components. -
-
-
-loose-object hardens objects added to the repo in loose-object form. -
-
-
-pack hardens objects added to the repo in packfile form. -
-
-
-pack-metadata hardens packfile bitmaps and indexes. -
-
-
-commit-graph hardens the commit-graph file. + Use customized color for diff colorization. <slot> specifies + which part of the patch to use the specified color, and is one + of context (context text - plain is a historical synonym), + meta (metainformation), frag + (hunk header), func (function in hunk header), old (removed lines), + new (added lines), commit (commit headers), whitespace + (highlighting whitespace errors), oldMoved (deleted lines), + newMoved (added lines), oldMovedDimmed, oldMovedAlternative, + oldMovedAlternativeDimmed, newMovedDimmed, newMovedAlternative + newMovedAlternativeDimmed (See the <mode> + setting of --color-moved in git-diff(1) for details), + contextDimmed, oldDimmed, newDimmed, contextBold, + oldBold, and newBold (see git-range-diff(1) for details).
-
+

+color.decorate.<slot> +

-index hardens the index when it is modified. + Use customized color for git log --decorate output. <slot> is one + of branch, remoteBranch, tag, stash or HEAD for local + branches, remote-tracking branches, tags, stash and HEAD, respectively + and grafted for grafted commits.

- -

+color.grep +

-objects is an aggregate option that is equivalent to - loose-object,pack. + When set to always, always highlight matches. When false (or + never), never. When set to true or auto, use color only + when the output is written to the terminal. If unset, then the + value of color.ui is used (auto by default).

- -

+color.grep.<slot> +

-reference hardens references modified in the repo. + Use customized color for grep colorization. <slot> specifies which + part of the line to use the specified color, and is one of

- -

+context +: -derived-metadata is an aggregate option that is equivalent to - pack-metadata,commit-graph. + non-matching text in context lines (when using -A, -B, or -C)
-

+filename +

-committed is an aggregate option that is currently equivalent to - objects. This mode sacrifices some performance to ensure that work - that is committed to the repository with git commit or similar commands - is hardened. + filename prefix (when not using -h)

- -

+function +

-added is an aggregate option that is currently equivalent to - committed,index. This mode sacrifices additional performance to - ensure that the results of commands like git add and similar operations - are hardened. + function name lines (when using -p)

- -

+lineNumber +

-all is an aggregate option that syncs all individual components above. + line number prefix (when using -n)

- -

-core.fsyncMethod +column

- A value indicating the strategy Git will use to harden repository data - using fsync and related primitives. + column number prefix (when using --column)

+match +

-fsync uses the fsync() system call or platform equivalents. + matching text (same as setting matchContext and matchSelected)

- -

+matchContext +

-writeout-only issues pagecache writeback requests, but depending on the - filesystem and storage hardware, data added to the repository may not be - durable in the event of a system crash. This is the default mode on macOS. + matching text in context lines

- -

+matchSelected +

-batch enables a mode that uses writeout-only flushes to stage multiple - updates in the disk writeback cache and then does a single full fsync of - a dummy file to trigger the disk cache flush at the end of the operation. + matching text in selected lines. Also, used to customize the following + git-log(1) subcommands: --grep, --author, and --committer.

Currently batch mode only applies to loose-object files. Other repository -data is made durable as if fsync was specified. This mode is expected to -be as safe as fsync on macOS for repos stored on HFS+ or APFS filesystems -and on Windows for repos stored on NTFS or ReFS filesystems.

- -

-core.fsyncObjectFiles +selected

- This boolean will enable fsync() when writing object files. - This setting is deprecated. Use core.fsync instead. + non-matching text in selected lines. Also, used to customize the + following git-log(1) subcommands: --grep, --author and + --committer.

This setting affects data added to the Git repository in loose-object -form. When set to true, Git will issue an fsync or similar system call -to flush caches so that loose-objects remain consistent in the face -of a unclean system shutdown.

-core.preloadIndex +separator

- Enable parallel index preload for operations like git diff + separators between fields on a line (:, -, and =) + and between hunks (--)

This can speed up operations like git diff and git status especially -on filesystems like NFS that have weak caching semantics and thus -relatively high IO latencies. When enabled, Git will do the -index comparison to the filesystem data in parallel, allowing -overlapping IO’s. Defaults to true.

-core.unsetenvvars +color.interactive

- Windows-only: comma-separated list of environment variables' - names that need to be unset before spawning any other process. - Defaults to PERL5LIB to account for the fact that Git for - Windows insists on using its own Perl interpreter. + When set to always, always use colors for interactive prompts + and displays (such as those used by "git-add --interactive" and + "git-clean --interactive"). When false (or never), never. + When set to true or auto, use colors only when the output is + to the terminal. If unset, then the value of color.ui is + used (auto by default).

-core.restrictinheritedhandles +color.interactive.<slot>

- Windows-only: override whether spawned processes inherit only standard - file handles (stdin, stdout and stderr) or all handles. Can be - auto, true or false. Defaults to auto, which means true on - Windows 7 and later, and false on older Windows versions. + Use customized color for git add --interactive and git clean + --interactive output. <slot> may be prompt, header, help + or error, for four distinct types of normal output from + interactive commands.

-core.createObject +color.pager

- You can set this to link, in which case a hardlink followed by - a delete of the source are used to make sure that object creation - will not overwrite existing objects. + A boolean to specify whether auto color modes should colorize + output going to the pager. Defaults to true; set this to false + if your pager does not understand ANSI color codes.

On some file system/operating system combinations, this is unreliable. -Set this config setting to rename there; However, This will remove the -check that makes sure that existing object files will not get overwritten.

-core.notesRef +color.push

- When showing commit messages, also show notes which are stored in - the given ref. The ref must be fully qualified. If the given - ref does not exist, it is not an error but means that no - notes should be printed. + A boolean to enable/disable color in push errors. May be set to + always, false (or never) or auto (or true), in which + case colors are used only when the error output goes to a terminal. + If unset, then the value of color.ui is used (auto by default).

This setting defaults to "refs/notes/commits", and it can be overridden by -the GIT_NOTES_REF environment variable. See git-notes(1).

-core.commitGraph +color.push.error

- If true, then git will read the commit-graph file (if it exists) - to parse the graph structure of commits. Defaults to true. See - git-commit-graph(1) for more information. + Use customized color for push errors.

-core.useReplaceRefs +color.remote

- If set to false, behave as if the --no-replace-objects - option was given on the command line. See git(1) and - git-replace(1) for more information. + If set, keywords at the start of the line are highlighted. The + keywords are "error", "warning", "hint" and "success", and are + matched case-insensitively. May be set to always, false (or + never) or auto (or true). If unset, then the value of + color.ui is used (auto by default).

-core.multiPackIndex +color.remote.<slot>

- Use the multi-pack-index file to track multiple packfiles using a - single index. See git-multi-pack-index(1) for more - information. Defaults to true. + Use customized color for each remote keyword. <slot> may be + hint, warning, success or error which match the + corresponding keyword.

-core.sparseCheckout +color.showBranch

- Enable "sparse checkout" feature. See git-sparse-checkout(1) - for more information. + A boolean to enable/disable color in the output of + git-show-branch(1). May be set to always, + false (or never) or auto (or true), in which case colors are used + only when the output is to a terminal. If unset, then the + value of color.ui is used (auto by default).

-core.sparseCheckoutCone +color.status

- Enables the "cone mode" of the sparse checkout feature. When the - sparse-checkout file contains a limited set of patterns, this - mode provides significant performance advantages. The "non-cone - mode" can be requested to allow specifying more flexible - patterns by setting this variable to false. See - git-sparse-checkout(1) for more information. + A boolean to enable/disable color in the output of + git-status(1). May be set to always, + false (or never) or auto (or true), in which case colors are used + only when the output is to a terminal. If unset, then the + value of color.ui is used (auto by default).

-core.abbrev +color.status.<slot>

- Set the length object names are abbreviated to. If - unspecified or set to "auto", an appropriate value is - computed based on the approximate number of packed objects - in your repository, which hopefully is enough for - abbreviated object names to stay unique for some time. - If set to "no", no abbreviation is made and the object names - are shown in their full length. - The minimum length is 4. + Use customized color for status colorization. <slot> is + one of header (the header text of the status message), + added or updated (files which are added but not committed), + changed (files which are changed but not added in the index), + untracked (files which are not tracked by Git), + branch (the current branch), + nobranch (the color the no branch warning is shown in, defaulting + to red), + localBranch or remoteBranch (the local and remote branch names, + respectively, when branch and tracking information is displayed in the + status short-format), or + unmerged (files which have unmerged changes).

-core.maxTreeDepth +color.transport

- The maximum depth Git is willing to recurse while traversing a - tree (e.g., "a/b/cde/f" has a depth of 4). This is a fail-safe - to allow Git to abort cleanly, and should not generally need to - be adjusted. The default is 4096. + A boolean to enable/disable color when pushes are rejected. May be + set to always, false (or never) or auto (or true), in which + case colors are used only when the error output goes to a terminal. + If unset, then the value of color.ui is used (auto by default).

-add.ignoreErrors +color.transport.rejected

+ Use customized color when a push was rejected. +

-add.ignore-errors (deprecated) +color.ui

- Tells git add to continue adding files when some files cannot be - added due to indexing errors. Equivalent to the --ignore-errors - option of git-add(1). add.ignore-errors is deprecated, - as it does not follow the usual naming convention for configuration - variables. + This variable determines the default value for variables such + as color.diff and color.grep that control the use of color + per command family. Its scope will expand as more commands learn + configuration to set a default for the --color option. Set it + to false or never if you prefer Git commands not to use + color unless enabled explicitly with some other configuration + or the --color option. Set it to always if you want all + output not intended for machine consumption to use color, to + true or auto (this is the default since Git 1.8.4) if you + want such output to use color when written to the terminal.

-add.interactive.useBuiltin +column.ui

- Unused configuration variable. Used in Git versions v2.25.0 to - v2.36.0 to enable the built-in version of git-add(1)'s - interactive mode, which then became the default in Git - versions v2.37.0 to v2.39.0. + Specify whether supported commands should output in columns. + This variable consists of a list of tokens separated by spaces + or commas:

These options control when the feature should be enabled +(defaults to never):

-alias.* +always: - Command aliases for the git(1) command wrapper - e.g. - after defining alias.last = cat-file commit HEAD, the invocation - git last is equivalent to git cat-file commit HEAD. To avoid - confusion and troubles with script usage, aliases that - hide existing Git commands are ignored. Arguments are split by - spaces, the usual shell quoting and escaping are supported. - A quote pair or a backslash can be used to quote them. + always show in columns
-
Note that the first word of an alias does not necessarily have to be a -command. It can be a command-line option that will be passed into the -invocation of git. In particular, this is useful when used with -c -to pass in one-time configurations or -p to force pagination. For example, -loud-rebase = -c commit.verbose=true rebase can be defined such that -running git loud-rebase would be equivalent to -git -c commit.verbose=true rebase. Also, ps = -p status would be a -helpful alias since git ps would paginate the output of git status -where the original command does not.
-
If the alias expansion is prefixed with an exclamation point, -it will be treated as a shell command. For example, defining -alias.new = !gitk --all --not ORIG_HEAD, the invocation -git new is equivalent to running the shell command -gitk --all --not ORIG_HEAD. Note that shell commands will be -executed from the top-level directory of a repository, which may -not necessarily be the current directory. -GIT_PREFIX is set as returned by running git rev-parse --show-prefix -from the original current directory. See git-rev-parse(1).
-am.keepcr +never: - If true, git-am will call git-mailsplit for patches in mbox format - with parameter --keep-cr. In this case git-mailsplit will - not remove \r from lines ending with \r\n. Can be overridden - by giving --no-keep-cr from the command line. - See git-am(1), git-mailsplit(1). + never show in columns
-am.threeWay +auto: - By default, git am will fail if the patch does not apply cleanly. When - set to true, this setting tells git am to fall back on 3-way merge if - the patch records the identity of blobs it is supposed to apply to and - we have those blobs available locally (equivalent to giving the --3way - option from the command line). Defaults to false. - See git-am(1). + show in columns if the output is to the terminal

These options control layout (defaults to column). Setting any +of these implies always if none of always, never, or auto are +specified.

-apply.ignoreWhitespace +column: - When set to change, tells git apply to ignore changes in - whitespace, in the same way as the --ignore-space-change - option. - When set to one of: no, none, never, false, it tells git apply to - respect all whitespace differences. - See git-apply(1). + fill columns before rows
-apply.whitespace +row: - Tells git apply how to handle whitespace, in the same way - as the --whitespace option. See git-apply(1). + fill rows before columns
-blame.blankBoundary +plain: - Show blank commit object name for boundary commits in - git-blame(1). This option defaults to false. + show in one column

Finally, these options can be combined with a layout option (defaults +to nodense):

-blame.coloring +dense: - This determines the coloring scheme to be applied to blame - output. It can be repeatedLines, highlightRecent, - or none which is the default. + make unequal size columns to utilize more space
-blame.date +nodense: - Specifies the format used to output dates in git-blame(1). - If unset the iso format is used. For supported values, - see the discussion of the --date option at git-log(1). + make equal size columns

-blame.showEmail +column.branch

- Show the author email instead of author name in git-blame(1). - This option defaults to false. + Specify whether to output branch listing in git branch in columns. + See column.ui for details.

-blame.showRoot +column.clean

- Do not treat root commits as boundaries in git-blame(1). - This option defaults to false. + Specify the layout when listing items in git clean -i, which always + shows files and directories in columns. See column.ui for details.

-blame.ignoreRevsFile +column.status

- Ignore revisions listed in the file, one unabbreviated object name per - line, in git-blame(1). Whitespace and comments beginning with - # are ignored. This option may be repeated multiple times. Empty - file names will reset the list of ignored revisions. This option will - be handled before the command line option --ignore-revs-file. + Specify whether to output untracked files in git status in columns. + See column.ui for details.

-blame.markUnblamableLines +column.tag

- Mark lines that were changed by an ignored revision that we could not - attribute to another commit with a * in the output of - git-blame(1). + Specify whether to output tag listings in git tag in columns. + See column.ui for details.

-blame.markIgnoredLines +commit.cleanup

- Mark lines that were changed by an ignored revision that we attributed to - another commit with a ? in the output of git-blame(1). + This setting overrides the default of the --cleanup option in + git commit. See git-commit(1) for details. Changing the + default can be useful when you always want to keep lines that begin + with the comment character # in your log message, in which case you + would do git config commit.cleanup whitespace (note that you will + have to remove the help lines that begin with # in the commit log + template yourself, if you do this).

-branch.autoSetupMerge +commit.gpgSign

- Tells git branch, git switch and git checkout to set up new branches - so that git-pull(1) will appropriately merge from the - starting point branch. Note that even if this option is not set, - this behavior can be chosen per-branch using the --track - and --no-track options. The valid settings are: false — no - automatic setup is done; true — automatic setup is done when the - starting point is a remote-tracking branch; always — automatic setup is done when the starting point is either a - local branch or remote-tracking branch; inherit — if the starting point - has a tracking configuration, it is copied to the new - branch; simple — automatic setup is done only when the starting point - is a remote-tracking branch and the new branch has the same name as the - remote branch. This option defaults to true. + A boolean to specify whether all commits should be GPG signed. + Use of this option when doing operations such as rebase can + result in a large number of commits being signed. It may be + convenient to use an agent to avoid typing your GPG passphrase + several times.

-branch.autoSetupRebase +commit.status

- When a new branch is created with git branch, git switch or git checkout - that tracks another branch, this variable tells Git to set - up pull to rebase instead of merge (see "branch.<name>.rebase"). - When never, rebase is never automatically set to true. - When local, rebase is set to true for tracked branches of - other local branches. - When remote, rebase is set to true for tracked branches of - remote-tracking branches. - When always, rebase will be set to true for all tracking - branches. - See "branch.autoSetupMerge" for details on how to set up a - branch to track another branch. - This option defaults to never. + A boolean to enable/disable inclusion of status information in the + commit message template when using an editor to prepare the commit + message. Defaults to true.

-branch.sort +commit.template

- This variable controls the sort ordering of branches when displayed by - git-branch(1). Without the "--sort=<value>" option provided, the - value of this variable will be used as the default. - See git-for-each-ref(1) field names for valid values. + Specify the pathname of a file to use as the template for + new commit messages.

-branch.<name>.remote +commit.verbose

- When on branch <name>, it tells git fetch and git push - which remote to fetch from or push to. The remote to push to - may be overridden with remote.pushDefault (for all branches). - The remote to push to, for the current branch, may be further - overridden by branch.<name>.pushRemote. If no remote is - configured, or if you are not on any branch and there is more than - one remote defined in the repository, it defaults to origin for - fetching and remote.pushDefault for pushing. - Additionally, . (a period) is the current local repository - (a dot-repository), see branch.<name>.merge's final note below. + A boolean or int to specify the level of verbosity with git commit. + See git-commit(1).

-branch.<name>.pushRemote +commitGraph.generationVersion

- When on branch <name>, it overrides branch.<name>.remote for - pushing. It also overrides remote.pushDefault for pushing - from branch <name>. When you pull from one place (e.g. your - upstream) and push to another place (e.g. your own publishing - repository), you would want to set remote.pushDefault to - specify the remote to push to for all branches, and use this - option to override it for a specific branch. + Specifies the type of generation number version to use when writing + or reading the commit-graph file. If version 1 is specified, then + the corrected commit dates will not be written or read. Defaults to + 2.

-branch.<name>.merge +commitGraph.maxNewFilters

- Defines, together with branch.<name>.remote, the upstream branch - for the given branch. It tells git fetch/git pull/git rebase which - branch to merge and can also affect git push (see push.default). - When in branch <name>, it tells git fetch the default - refspec to be marked for merging in FETCH_HEAD. The value is - handled like the remote part of a refspec, and must match a - ref which is fetched from the remote given by - "branch.<name>.remote". - The merge information is used by git pull (which first calls - git fetch) to lookup the default branch for merging. Without - this option, git pull defaults to merge the first refspec fetched. - Specify multiple values to get an octopus merge. - If you wish to setup git pull so that it merges into <name> from - another branch in the local repository, you can point - branch.<name>.merge to the desired branch, and use the relative path - setting . (a period) for branch.<name>.remote. + Specifies the default value for the --max-new-filters option of git + commit-graph write (c.f., git-commit-graph(1)).

-branch.<name>.mergeOptions +commitGraph.readChangedPaths

- Sets default options for merging into branch <name>. The syntax and - supported options are the same as those of git-merge(1), but - option values containing whitespace characters are currently not - supported. + If true, then git will use the changed-path Bloom filters in the + commit-graph file (if it exists, and they are present). Defaults to + true. See git-commit-graph(1) for more information.

-branch.<name>.rebase +completion.commands

- When true, rebase the branch <name> on top of the fetched branch, - instead of merging the default branch from the default remote when - "git pull" is run. See "pull.rebase" for doing this in a non - branch-specific manner. + This is only used by git-completion.bash to add or remove + commands from the list of completed commands. Normally only + porcelain commands and a few select others are completed. You + can add more commands, separated by space, in this + variable. Prefixing the command with - will remove it from + the existing list.

When merges (or just m), pass the --rebase-merges option to git rebase -so that the local merge commits are included in the rebase (see -git-rebase(1) for details).

When the value is interactive (or just i), the rebase is run in interactive -mode.

NOTE: this is a possibly dangerous operation; do not use -it unless you understand the implications (see git-rebase(1) -for details).

-branch.<name>.description +core.fileMode

- Branch description, can be edited with - git branch --edit-description. Branch description is - automatically added to the format-patch cover letter or - request-pull summary. + Tells Git if the executable bit of files in the working tree + is to be honored.

Some filesystems lose the executable bit when a file that is +marked as executable is checked out, or checks out a +non-executable file with executable bit on. +git-clone(1) or git-init(1) probe the filesystem +to see if it handles the executable bit correctly +and this variable is automatically set as necessary.

A repository, however, may be on a filesystem that handles +the filemode correctly, and this variable is set to true +when created, but later may be made accessible from another +environment that loses the filemode (e.g. exporting ext4 via +CIFS mount, visiting a Cygwin created repository with +Git for Windows or Eclipse). +In such a case it may be necessary to set this variable to false. +See git-update-index(1).

The default is true (when core.filemode is not specified in the config file).

-browser.<tool>.cmd +core.hideDotFiles

- Specify the command to invoke the specified browser. The - specified command is evaluated in shell with the URLs passed - as arguments. (See git-web--browse(1).) + (Windows-only) If true, mark newly-created directories and files whose + name starts with a dot as hidden. If dotGitOnly, only the .git/ + directory is hidden, but no other files starting with a dot. The + default mode is dotGitOnly.

-browser.<tool>.path +core.ignoreCase

- Override the path for the given tool that may be used to - browse HTML help (see -w option in git-help(1)) or a - working repository in gitweb (see git-instaweb(1)). + Internal variable which enables various workarounds to enable + Git to work better on filesystems that are not case sensitive, + like APFS, HFS+, FAT, NTFS, etc. For example, if a directory listing + finds "makefile" when Git expects "Makefile", Git will assume + it is really the same file, and continue to remember it as + "Makefile".

The default is false, except git-clone(1) or git-init(1) +will probe and set core.ignoreCase true if appropriate when the repository +is created.

Git relies on the proper configuration of this variable for your operating +and file system. Modifying this value may result in unexpected behavior.

-bundle.* +core.precomposeUnicode

- The bundle.* keys may appear in a bundle list file found via the - git clone --bundle-uri option. These keys currently have no effect - if placed in a repository config file, though this will change in the - future. See the bundle URI design - document for more details. + This option is only used by Mac OS implementation of Git. + When core.precomposeUnicode=true, Git reverts the unicode decomposition + of filenames done by Mac OS. This is useful when sharing a repository + between Mac OS and Linux or Windows. + (Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7). + When false, file names are handled fully transparent by Git, + which is backward compatible with older versions of Git.

-bundle.version +core.protectHFS

- This integer value advertises the version of the bundle list format - used by the bundle list. Currently, the only accepted value is 1. + If set to true, do not allow checkout of paths that would + be considered equivalent to .git on an HFS+ filesystem. + Defaults to true on Mac OS, and false elsewhere.

-bundle.mode +core.protectNTFS

- This string value should be either all or any. This value describes - whether all of the advertised bundles are required to unbundle a - complete understanding of the bundled information (all) or if any one - of the listed bundle URIs is sufficient (any). + If set to true, do not allow checkout of paths that would + cause problems with the NTFS filesystem, e.g. conflict with + 8.3 "short" names. + Defaults to true on Windows, and false elsewhere.

-bundle.heuristic +core.fsmonitor

- If this string-valued key exists, then the bundle list is designed to - work well with incremental git fetch commands. The heuristic signals - that there are additional keys available for each bundle that help - determine which subset of bundles the client should download. The - only value currently understood is creationToken. + If set to true, enable the built-in file system monitor + daemon for this working directory (git-fsmonitor--daemon(1)).

Like hook-based file system monitors, the built-in file system monitor +can speed up Git commands that need to refresh the Git index +(e.g. git status) in a working directory with many files. The +built-in monitor eliminates the need to install and maintain an +external third-party tool.

The built-in file system monitor is currently available only on a +limited set of supported platforms. Currently, this includes Windows +and MacOS.

Otherwise, this variable contains the pathname of the "fsmonitor"
+hook command.

This hook command is used to identify all files that may have changed +since the requested date/time. This information is used to speed up +git by avoiding unnecessary scanning of files that have not changed.

See the "fsmonitor-watchman" section of githooks(5).

Note that if you concurrently use multiple versions of Git, such +as one version on the command line and another version in an IDE +tool, that the definition of core.fsmonitor was extended to +allow boolean values in addition to hook pathnames. Git versions +2.35.1 and prior will not understand the boolean values and will +consider the "true" or "false" values as hook pathnames to be +invoked. Git versions 2.26 thru 2.35.1 default to hook protocol +V2 and will fall back to no fsmonitor (full scan). Git versions +prior to 2.26 default to hook protocol V1 and will silently +assume there were no changes to report (no scan), so status +commands may report incomplete results. For this reason, it is +best to upgrade all of your Git versions before using the built-in +file system monitor.

-bundle.<id>.* +core.fsmonitorHookVersion

- The bundle.<id>.* keys are used to describe a single item in the - bundle list, grouped under <id> for identification purposes. + Sets the protocol version to be used when invoking the + "fsmonitor" hook.

There are currently versions 1 and 2. When this is not set, +version 2 will be tried first and if it fails then version 1 +will be tried. Version 1 uses a timestamp as input to determine +which files have changes since that time but some monitors +like Watchman have race conditions when used with a timestamp. +Version 2 uses an opaque string so that the monitor can return +something that can be used to determine what files have changed +without race conditions.

-bundle.<id>.uri +core.trustctime

- This string value defines the URI by which Git can reach the contents - of this <id>. This URI may be a bundle file or another bundle list. + If false, the ctime differences between the index and the + working tree are ignored; useful when the inode change time + is regularly modified by something outside Git (file system + crawlers and some backup systems). + See git-update-index(1). True by default.

-checkout.defaultRemote +core.splitIndex

- When you run git checkout <something> - or git switch <something> and only have one - remote, it may implicitly fall back on checking out and - tracking e.g. origin/<something>. This stops working as soon - as you have more than one remote with a <something> - reference. This setting allows for setting the name of a - preferred remote that should always win when it comes to - disambiguation. The typical use-case is to set this to - origin. + If true, the split-index feature of the index will be used. + See git-update-index(1). False by default.

Currently this is used by git-switch(1) and -git-checkout(1) when git checkout <something> -or git switch <something> -will checkout the <something> branch on another remote, -and by git-worktree(1) when git worktree add refers to a -remote branch. This setting might be used for other checkout-like -commands or functionality in the future.

-checkout.guess +core.untrackedCache

- Provides the default value for the --guess or --no-guess - option in git checkout and git switch. See - git-switch(1) and git-checkout(1). + Determines what to do about the untracked cache feature of the + index. It will be kept, if this variable is unset or set to + keep. It will automatically be added if set to true. And + it will automatically be removed, if set to false. Before + setting it to true, you should check that mtime is working + properly on your system. + See git-update-index(1). keep by default, unless + feature.manyFiles is enabled which sets this setting to + true by default.

-checkout.workers +core.checkStat

- The number of parallel workers to use when updating the working tree. - The default is one, i.e. sequential execution. If set to a value less - than one, Git will use as many workers as the number of logical cores - available. This setting and checkout.thresholdForParallelism affect - all commands that perform checkout. E.g. checkout, clone, reset, - sparse-checkout, etc. + When missing or is set to default, many fields in the stat + structure are checked to detect if a file has been modified + since Git looked at it. When this configuration variable is + set to minimal, sub-second part of mtime and ctime, the + uid and gid of the owner of the file, the inode number (and + the device number, if Git was compiled to use it), are + excluded from the check among these fields, leaving only the + whole-second part of mtime (and ctime, if core.trustCtime + is set) and the filesize to be checked.

Note: Parallel checkout usually delivers better performance for repositories -located on SSDs or over NFS. For repositories on spinning disks and/or machines -with a small number of cores, the default sequential checkout often performs -better. The size and compression level of a repository might also influence how -well the parallel version performs.

There are implementations of Git that do not leave usable values in +some fields (e.g. JGit); by excluding these fields from the +comparison, the minimal mode may help interoperability when the +same repository is used by these other systems at the same time.

-checkout.thresholdForParallelism +core.quotePath

- When running parallel checkout with a small number of files, the cost - of subprocess spawning and inter-process communication might outweigh - the parallelization gains. This setting allows you to define the minimum - number of files for which parallel checkout should be attempted. The - default is 100. + Commands that output paths (e.g. ls-files, diff), will + quote "unusual" characters in the pathname by enclosing the + pathname in double-quotes and escaping those characters with + backslashes in the same way C escapes control characters (e.g. + \t for TAB, \n for LF, \\ for backslash) or bytes with + values larger than 0x80 (e.g. octal \302\265 for "micro" in + UTF-8). If this variable is set to false, bytes higher than + 0x80 are not considered "unusual" any more. Double-quotes, + backslash and control characters are always escaped regardless + of the setting of this variable. A simple space character is + not considered "unusual". Many commands can output pathnames + completely verbatim using the -z option. The default value + is true.

-clean.requireForce +core.eol

- A boolean to make git-clean do nothing unless given -f, - -i, or -n. Defaults to true. + Sets the line ending type to use in the working directory for + files that are marked as text (either by having the text + attribute set, or by having text=auto and Git auto-detecting + the contents as text). + Alternatives are lf, crlf and native, which uses the platform’s + native line ending. The default value is native. See + gitattributes(5) for more information on end-of-line + conversion. Note that this value is ignored if core.autocrlf + is set to true or input.

-clone.defaultRemoteName +core.safecrlf

- The name of the remote to create when cloning a repository. Defaults to - origin, and can be overridden by passing the --origin command-line - option to git-clone(1). + If true, makes Git check if converting CRLF is reversible when + end-of-line conversion is active. Git will verify if a command + modifies a file in the work tree either directly or indirectly. + For example, committing a file followed by checking out the + same file should yield the original file in the work tree. If + this is not the case for the current setting of + core.autocrlf, Git will reject the file. The variable can + be set to "warn", in which case Git will only warn about an + irreversible conversion but continue the operation.

CRLF conversion bears a slight chance of corrupting data. +When it is enabled, Git will convert CRLF to LF during commit and LF to +CRLF during checkout. A file that contains a mixture of LF and +CRLF before the commit cannot be recreated by Git. For text +files this is the right thing to do: it corrects line endings +such that we have only LF line endings in the repository. +But for binary files that are accidentally classified as text the +conversion can corrupt data.

If you recognize such corruption early you can easily fix it by +setting the conversion type explicitly in .gitattributes. Right +after committing you still have the original file in your work +tree and this file is not yet corrupted. You can explicitly tell +Git that this file is binary and Git will handle the file +appropriately.

Unfortunately, the desired effect of cleaning up text files with +mixed line endings and the undesired effect of corrupting binary +files cannot be distinguished. In both cases CRLFs are removed +in an irreversible way. For text files this is the right thing +to do because CRLFs are line endings, while for binary files +converting CRLFs corrupts data.

Note, this safety check does not mean that a checkout will generate a +file identical to the original file for a different setting of +core.eol and core.autocrlf, but only for the current one. For +example, a text file with LF would be accepted with core.eol=lf +and could later be checked out with core.eol=crlf, in which case the +resulting file would contain CRLF, although the original file +contained LF. However, in both work trees the line endings would be +consistent, that is either all LF or all CRLF, but never mixed. A +file with mixed line endings would be reported by the core.safecrlf +mechanism.

-clone.rejectShallow +core.autocrlf

- Reject cloning a repository if it is a shallow one; this can be overridden by - passing the --reject-shallow option on the command line. See git-clone(1) + Setting this variable to "true" is the same as setting + the text attribute to "auto" on all files and core.eol to "crlf". + Set to true if you want to have CRLF line endings in your + working directory and the repository has LF line endings. + This variable can be set to input, + in which case no output conversion is performed.

-clone.filterSubmodules +core.checkRoundtripEncoding

- If a partial clone filter is provided (see --filter in - git-rev-list(1)) and --recurse-submodules is used, also apply - the filter to submodules. + A comma and/or whitespace separated list of encodings that Git + performs UTF-8 round trip checks on if they are used in an + working-tree-encoding attribute (see gitattributes(5)). + The default value is SHIFT-JIS.

-color.advice +core.symlinks

- A boolean to enable/disable color in hints (e.g. when a push - failed, see advice.* for a list). May be set to always, - false (or never) or auto (or true), in which case colors - are used only when the error output goes to a terminal. If - unset, then the value of color.ui is used (auto by default). + If false, symbolic links are checked out as small plain files that + contain the link text. git-update-index(1) and + git-add(1) will not change the recorded type to regular + file. Useful on filesystems like FAT that do not support + symbolic links.

The default is true, except git-clone(1) or git-init(1) +will probe and set core.symlinks false if appropriate when the repository +is created.

-color.advice.hint +core.gitProxy

- Use customized color for hints. + A "proxy command" to execute (as command host port) instead + of establishing direct connection to the remote server when + using the Git protocol for fetching. If the variable value is + in the "COMMAND for DOMAIN" format, the command is applied only + on hostnames ending with the specified domain string. This variable + may be set multiple times and is matched in the given order; + the first match wins.

Can be overridden by the GIT_PROXY_COMMAND environment variable +(which always applies universally, without the special "for" +handling).

The special string none can be used as the proxy command to +specify that no proxy be used for a given domain pattern. +This is useful for excluding servers inside a firewall from +proxy use, while defaulting to a common proxy for external domains.

-color.blame.highlightRecent +core.sshCommand

- Specify the line annotation color for git blame --color-by-age - depending upon the age of the line. -

This setting should be set to a comma-separated list of color and -date settings, starting and ending with a color, the dates should be -set from oldest to newest. The metadata will be colored with the -specified colors if the line was introduced before the given -timestamp, overwriting older timestamped colors.

Instead of an absolute timestamp relative timestamps work as well, -e.g. 2.weeks.ago is valid to address anything older than 2 weeks.

It defaults to blue,12 month ago,white,1 month ago,red, which -colors everything older than one year blue, recent changes between -one month and one year old are kept white, and lines introduced -within the last month are colored red.

+ If this variable is set, git fetch and git push will + use the specified command instead of ssh when they need to + connect to a remote system. The command is in the same form as + the GIT_SSH_COMMAND environment variable and is overridden + when the environment variable is set. +

-color.blame.repeatedLines +core.ignoreStat

- Use the specified color to colorize line annotations for - git blame --color-lines, if they come from the same commit as the - preceding line. Defaults to cyan. + If true, Git will avoid using lstat() calls to detect if files have + changed by setting the "assume-unchanged" bit for those tracked files + which it has updated identically in both the index and working tree.

When files are modified outside of Git, the user will need to stage +the modified files explicitly (e.g. see Examples section in +git-update-index(1)). +Git will not normally detect changes to those files.

This is useful on systems where lstat() calls are very slow, such as +CIFS/Microsoft Windows.

False by default.

-color.branch +core.preferSymlinkRefs

- A boolean to enable/disable color in the output of - git-branch(1). May be set to always, - false (or never) or auto (or true), in which case colors are used - only when the output is to a terminal. If unset, then the - value of color.ui is used (auto by default). + Instead of the default "symref" format for HEAD + and other symbolic reference files, use symbolic links. + This is sometimes needed to work with old scripts that + expect HEAD to be a symbolic link.

-color.branch.<slot> +core.alternateRefsCommand

- Use customized color for branch coloration. <slot> is one of - current (the current branch), local (a local branch), - remote (a remote-tracking branch in refs/remotes/), - upstream (upstream tracking branch), plain (other - refs). + When advertising tips of available history from an alternate, use the shell to + execute the specified command instead of git-for-each-ref(1). The + first argument is the absolute path of the alternate. Output must contain one + hex object id per line (i.e., the same as produced by git for-each-ref + --format='%(objectname)').

Note that you cannot generally put git for-each-ref directly into the config +value, as it does not take a repository path as an argument (but you can wrap +the command above in a shell script).

-color.diff +core.alternateRefsPrefixes

- Whether to use ANSI escape sequences to add color to patches. - If this is set to always, git-diff(1), - git-log(1), and git-show(1) will use color - for all patches. If it is set to true or auto, those - commands will only use color when output is to the terminal. - If unset, then the value of color.ui is used (auto by - default). + When listing references from an alternate, list only references that begin + with the given prefix. Prefixes match as if they were given as arguments to + git-for-each-ref(1). To list multiple prefixes, separate them with + whitespace. If core.alternateRefsCommand is set, setting + core.alternateRefsPrefixes has no effect.

This does not affect git-format-patch(1) or the -git-diff-* plumbing commands. Can be overridden on the -command line with the --color[=<when>] option.

-color.diff.<slot> +core.bare

- Use customized color for diff colorization. <slot> specifies - which part of the patch to use the specified color, and is one - of context (context text - plain is a historical synonym), - meta (metainformation), frag - (hunk header), func (function in hunk header), old (removed lines), - new (added lines), commit (commit headers), whitespace - (highlighting whitespace errors), oldMoved (deleted lines), - newMoved (added lines), oldMovedDimmed, oldMovedAlternative, - oldMovedAlternativeDimmed, newMovedDimmed, newMovedAlternative - newMovedAlternativeDimmed (See the <mode> - setting of --color-moved in git-diff(1) for details), - contextDimmed, oldDimmed, newDimmed, contextBold, - oldBold, and newBold (see git-range-diff(1) for details). + If true this repository is assumed to be bare and has no + working directory associated with it. If this is the case a + number of commands that require a working directory will be + disabled, such as git-add(1) or git-merge(1).

This setting is automatically guessed by git-clone(1) or +git-init(1) when the repository was created. By default a +repository that ends in "/.git" is assumed to be not bare (bare = +false), while all other repositories are assumed to be bare (bare += true).

-color.decorate.<slot> +core.worktree

- Use customized color for git log --decorate output. <slot> is one - of branch, remoteBranch, tag, stash or HEAD for local - branches, remote-tracking branches, tags, stash and HEAD, respectively - and grafted for grafted commits. + Set the path to the root of the working tree. + If GIT_COMMON_DIR environment variable is set, core.worktree + is ignored and not used for determining the root of working tree. + This can be overridden by the GIT_WORK_TREE environment + variable and the --work-tree command-line option. + The value can be an absolute path or relative to the path to + the .git directory, which is either specified by --git-dir + or GIT_DIR, or automatically discovered. + If --git-dir or GIT_DIR is specified but none of + --work-tree, GIT_WORK_TREE and core.worktree is specified, + the current working directory is regarded as the top level + of your working tree.

Note that this variable is honored even when set in a configuration +file in a ".git" subdirectory of a directory and its value differs +from the latter directory (e.g. "/path/to/.git/config" has +core.worktree set to "/different/path"), which is most likely a +misconfiguration. Running Git commands in the "/path/to" directory will +still use "/different/path" as the root of the work tree and can cause +confusion unless you know what you are doing (e.g. you are creating a +read-only snapshot of the same index to a location different from the +repository’s usual working tree).

-color.grep +core.logAllRefUpdates

- When set to always, always highlight matches. When false (or - never), never. When set to true or auto, use color only - when the output is written to the terminal. If unset, then the - value of color.ui is used (auto by default). + Enable the reflog. Updates to a ref <ref> is logged to the file + "$GIT_DIR/logs/<ref>", by appending the new and old + SHA-1, the date/time and the reason of the update, but + only when the file exists. If this configuration + variable is set to true, missing "$GIT_DIR/logs/<ref>" + file is automatically created for branch heads (i.e. under + refs/heads/), remote refs (i.e. under refs/remotes/), + note refs (i.e. under refs/notes/), and the symbolic ref HEAD. + If it is set to always, then a missing reflog is automatically + created for any ref under refs/.

This information can be used to determine what commit +was the tip of a branch "2 days ago".

This value is true by default in a repository that has +a working directory associated with it, and false by +default in a bare repository.

-color.grep.<slot> +core.repositoryFormatVersion

- Use customized color for grep colorization. <slot> specifies which - part of the line to use the specified color, and is one of + Internal variable identifying the repository format and layout + version.

-context +core.sharedRepository

- non-matching text in context lines (when using -A, -B, or -C) + When group (or true), the repository is made shareable between + several users in a group (making sure all the files and objects are + group-writable). When all (or world or everybody), the + repository will be readable by all users, additionally to being + group-shareable. When umask (or false), Git will use permissions + reported by umask(2). When 0xxx, where 0xxx is an octal number, + files in the repository will have this mode value. 0xxx will override + user’s umask value (whereas the other options will only override + requested parts of the user’s umask value). Examples: 0660 will make + the repo read/write-able for the owner and group, but inaccessible to + others (equivalent to group unless umask is e.g. 0022). 0640 is a + repository that is group-readable but not group-writable. + See git-init(1). False by default.

-filename +core.warnAmbiguousRefs

- filename prefix (when not using -h) + If true, Git will warn you if the ref name you passed it is ambiguous + and might match multiple refs in the repository. True by default.

-function +core.compression

- function name lines (when using -p) + An integer -1..9, indicating a default compression level. + -1 is the zlib default. 0 means no compression, + and 1..9 are various speed/size tradeoffs, 9 being slowest. + If set, this provides a default to other compression variables, + such as core.looseCompression and pack.compression.

-lineNumber +core.looseCompression

- line number prefix (when using -n) + An integer -1..9, indicating the compression level for objects that + are not in a pack file. -1 is the zlib default. 0 means no + compression, and 1..9 are various speed/size tradeoffs, 9 being + slowest. If not set, defaults to core.compression. If that is + not set, defaults to 1 (best speed).

-column +core.packedGitWindowSize

- column number prefix (when using --column) + Number of bytes of a pack file to map into memory in a + single mapping operation. Larger window sizes may allow + your system to process a smaller number of large pack files + more quickly. Smaller window sizes will negatively affect + performance due to increased calls to the operating system’s + memory manager, but may improve performance when accessing + a large number of large pack files.

Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32 +MiB on 32 bit platforms and 1 GiB on 64 bit platforms. This should +be reasonable for all users/operating systems. You probably do +not need to adjust this value.

Common unit suffixes of k, m, or g are supported.

-match +core.packedGitLimit

- matching text (same as setting matchContext and matchSelected) + Maximum number of bytes to map simultaneously into memory + from pack files. If Git needs to access more than this many + bytes at once to complete an operation it will unmap existing + regions to reclaim virtual address space within the process.

Default is 256 MiB on 32 bit platforms and 32 TiB (effectively +unlimited) on 64 bit platforms. +This should be reasonable for all users/operating systems, except on +the largest projects. You probably do not need to adjust this value.

Common unit suffixes of k, m, or g are supported.

-matchContext +core.deltaBaseCacheLimit

- matching text in context lines + Maximum number of bytes per thread to reserve for caching base objects + that may be referenced by multiple deltified objects. By storing the + entire decompressed base objects in a cache Git is able + to avoid unpacking and decompressing frequently used base + objects multiple times.

Default is 96 MiB on all platforms. This should be reasonable +for all users/operating systems, except on the largest projects. +You probably do not need to adjust this value.

Common unit suffixes of k, m, or g are supported.

-matchSelected +core.bigFileThreshold

- matching text in selected lines. Also, used to customize the following - git-log(1) subcommands: --grep, --author, and --committer. + The size of files considered "big", which as discussed below + changes the behavior of numerous git commands, as well as how + such files are stored within the repository. The default is + 512 MiB. Common unit suffixes of k, m, or g are + supported.

-selected -

Files above the configured limit will be:

- non-matching text in selected lines. Also, used to customize the - following git-log(1) subcommands: --grep, --author and - --committer. +Stored deflated in packfiles, without attempting delta compression. +
+
The default limit is primarily set with this use-case in mind. With it, +most projects will have their source code and other text files delta +compressed, but not larger binary media files.
+
Storing large files without delta compression avoids excessive memory +usage, at the slight expense of increased disk usage.
+
+
+Will be treated as if they were labeled "binary" (see + gitattributes(5)). e.g. git-log(1) and + git-diff(1) will not compute diffs for files above this limit. +
+
+
+Will generally be streamed when written, which avoids excessive +memory usage, at the cost of some fixed overhead. Commands that make +use of this include git-archive(1), +git-fast-import(1), git-index-pack(1), +git-unpack-objects(1) and git-fsck(1).
+

-separator +core.excludesFile

- separators between fields on a line (:, -, and =) - and between hunks (--) + Specifies the pathname to the file that contains patterns to + describe paths that are not meant to be tracked, in addition + to .gitignore (per-directory) and .git/info/exclude. + Defaults to $XDG_CONFIG_HOME/git/ignore. + If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore + is used instead. See gitignore(5).

-color.interactive +core.askPass

- When set to always, always use colors for interactive prompts - and displays (such as those used by "git-add --interactive" and - "git-clean --interactive"). When false (or never), never. - When set to true or auto, use colors only when the output is - to the terminal. If unset, then the value of color.ui is - used (auto by default). + Some commands (e.g. svn and http interfaces) that interactively + ask for a password can be told to use an external program given + via the value of this variable. Can be overridden by the GIT_ASKPASS + environment variable. If not set, fall back to the value of the + SSH_ASKPASS environment variable or, failing that, a simple password + prompt. The external program shall be given a suitable prompt as + command-line argument and write the password on its STDOUT.

-color.interactive.<slot> +core.attributesFile

- Use customized color for git add --interactive and git clean - --interactive output. <slot> may be prompt, header, help - or error, for four distinct types of normal output from - interactive commands. + In addition to .gitattributes (per-directory) and + .git/info/attributes, Git looks into this file for attributes + (see gitattributes(5)). Path expansions are made the same + way as for core.excludesFile. Its default value is + $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME is either not + set or empty, $HOME/.config/git/attributes is used instead.

-color.pager +core.hooksPath

- A boolean to specify whether auto color modes should colorize - output going to the pager. Defaults to true; set this to false - if your pager does not understand ANSI color codes. + By default Git will look for your hooks in the + $GIT_DIR/hooks directory. Set this to different path, + e.g. /etc/git/hooks, and Git will try to find your hooks in + that directory, e.g. /etc/git/hooks/pre-receive instead of + in $GIT_DIR/hooks/pre-receive.

The path can be either absolute or relative. A relative path is +taken as relative to the directory where the hooks are run (see +the "DESCRIPTION" section of githooks(5)).

This configuration variable is useful in cases where you’d like to +centrally configure your Git hooks instead of configuring them on a +per-repository basis, or as a more flexible and centralized +alternative to having an init.templateDir where you’ve changed +default hooks.

-color.push +core.editor

- A boolean to enable/disable color in push errors. May be set to - always, false (or never) or auto (or true), in which - case colors are used only when the error output goes to a terminal. - If unset, then the value of color.ui is used (auto by default). + Commands such as commit and tag that let you edit + messages by launching an editor use the value of this + variable when it is set, and the environment variable + GIT_EDITOR is not set. See git-var(1).

-color.push.error +core.commentChar

- Use customized color for push errors. + Commands such as commit and tag that let you edit + messages consider a line that begins with this character + commented, and removes them after the editor returns + (default #).

If set to "auto", git-commit would select a character that is not +the beginning character of any line in existing commit messages.

-color.remote +core.filesRefLockTimeout

- If set, keywords at the start of the line are highlighted. The - keywords are "error", "warning", "hint" and "success", and are - matched case-insensitively. May be set to always, false (or - never) or auto (or true). If unset, then the value of - color.ui is used (auto by default). + The length of time, in milliseconds, to retry when trying to + lock an individual reference. Value 0 means not to retry at + all; -1 means to try indefinitely. Default is 100 (i.e., + retry for 100ms).

-color.remote.<slot> +core.packedRefsTimeout

- Use customized color for each remote keyword. <slot> may be - hint, warning, success or error which match the - corresponding keyword. + The length of time, in milliseconds, to retry when trying to + lock the packed-refs file. Value 0 means not to retry at + all; -1 means to try indefinitely. Default is 1000 (i.e., + retry for 1 second).

-color.showBranch +core.pager

- A boolean to enable/disable color in the output of - git-show-branch(1). May be set to always, - false (or never) or auto (or true), in which case colors are used - only when the output is to a terminal. If unset, then the - value of color.ui is used (auto by default). + Text viewer for use by Git commands (e.g., less). The value + is meant to be interpreted by the shell. The order of preference + is the $GIT_PAGER environment variable, then core.pager + configuration, then $PAGER, and then the default chosen at + compile time (usually less).

When the LESS environment variable is unset, Git sets it to FRX +(if LESS environment variable is set, Git does not change it at +all). If you want to selectively override Git’s default setting +for LESS, you can set core.pager to e.g. less -S. This will +be passed to the shell by Git, which will translate the final +command to LESS=FRX less -S. The environment does not set the +S option but the command line does, instructing less to truncate +long lines. Similarly, setting core.pager to less -+F will +deactivate the F option specified by the environment from the +command-line, deactivating the "quit if one screen" behavior of +less. One can specifically activate some flags for particular +commands: for example, setting pager.blame to less -S enables +line truncation only for git blame.

Likewise, when the LV environment variable is unset, Git sets it +to -c. You can override this setting by exporting LV with +another value or setting core.pager to lv +c.

-color.status +core.whitespace

- A boolean to enable/disable color in the output of - git-status(1). May be set to always, - false (or never) or auto (or true), in which case colors are used - only when the output is to a terminal. If unset, then the - value of color.ui is used (auto by default). + A comma separated list of common whitespace problems to + notice. git diff will use color.diff.whitespace to + highlight them, and git apply --whitespace=error will + consider them as errors. You can prefix - to disable + any of them (e.g. -trailing-space):

-color.status.<slot> -

- Use customized color for status colorization. <slot> is - one of header (the header text of the status message), - added or updated (files which are added but not committed), - changed (files which are changed but not added in the index), - untracked (files which are not tracked by Git), - branch (the current branch), - nobranch (the color the no branch warning is shown in, defaulting - to red), - localBranch or remoteBranch (the local and remote branch names, - respectively, when branch and tracking information is displayed in the - status short-format), or - unmerged (files which have unmerged changes). +blank-at-eol treats trailing whitespaces at the end of the line + as an error (enabled by default). +
+
+
+space-before-tab treats a space character that appears immediately + before a tab character in the initial indent part of the line as an + error (enabled by default). +
+
+
+indent-with-non-tab treats a line that is indented with space + characters instead of the equivalent tabs as an error (not enabled by + default). +
+
+
+tab-in-indent treats a tab character in the initial indent part of + the line as an error (not enabled by default). +
+
+
+blank-at-eof treats blank lines added at the end of file as an error + (enabled by default). +
+
+
+trailing-space is a short-hand to cover both blank-at-eol and + blank-at-eof. +
+
+
+cr-at-eol treats a carriage-return at the end of line as + part of the line terminator, i.e. with it, trailing-space + does not trigger if the character before such a carriage-return + is not a whitespace (not enabled by default). +
+
+
+tabwidth=<n> tells how many character positions a tab occupies; this + is relevant for indent-with-non-tab and when Git fixes tab-in-indent + errors. The default tab width is 8. Allowed values are 1 to 63.
+

-color.transport +core.fsync

- A boolean to enable/disable color when pushes are rejected. May be - set to always, false (or never) or auto (or true), in which - case colors are used only when the error output goes to a terminal. - If unset, then the value of color.ui is used (auto by default). + A comma-separated list of components of the repository that + should be hardened via the core.fsyncMethod when created or + modified. You can disable hardening of any component by + prefixing it with a -. Items that are not hardened may be + lost in the event of an unclean system shutdown. Unless you + have special requirements, it is recommended that you leave + this option empty or pick one of committed, added, + or all. +

When this configuration is encountered, the set of components starts with +the platform default value, disabled components are removed, and additional +components are added. none resets the state so that the platform default +is ignored.

The empty string resets the fsync configuration to the platform +default. The default on most platforms is equivalent to +core.fsync=committed,-loose-object, which has good performance, +but risks losing recent work in the event of an unclean system shutdown.

+
+none clears the set of fsynced components. +
+
+
+loose-object hardens objects added to the repo in loose-object form. +
+
+
+pack hardens objects added to the repo in packfile form. +
+
+
+pack-metadata hardens packfile bitmaps and indexes. +
+
+
+commit-graph hardens the commit-graph file. +
+
+
+index hardens the index when it is modified.
-

-color.transport.rejected -

+ +

- Use customized color when a push was rejected. +objects is an aggregate option that is equivalent to + loose-object,pack.

-color.ui -

+ +

- This variable determines the default value for variables such - as color.diff and color.grep that control the use of color - per command family. Its scope will expand as more commands learn - configuration to set a default for the --color option. Set it - to false or never if you prefer Git commands not to use - color unless enabled explicitly with some other configuration - or the --color option. Set it to always if you want all - output not intended for machine consumption to use color, to - true or auto (this is the default since Git 1.8.4) if you - want such output to use color when written to the terminal. +reference hardens references modified in the repo.

-column.ui -

+ +

- Specify whether supported commands should output in columns. - This variable consists of a list of tokens separated by spaces - or commas: +derived-metadata is an aggregate option that is equivalent to + pack-metadata,commit-graph.

These options control when the feature should be enabled -(defaults to never):

-always -: +

- always show in columns +committed is an aggregate option that is currently equivalent to + objects. This mode sacrifices some performance to ensure that work + that is committed to the repository with git commit or similar commands + is hardened.

-never -

+ +

- never show in columns +added is an aggregate option that is currently equivalent to + committed,index. This mode sacrifices additional performance to + ensure that the results of commands like git add and similar operations + are hardened.

-auto -

+ +

- show in columns if the output is to the terminal +all is an aggregate option that syncs all individual components above.

- -

These options control layout (defaults to column). Setting any -of these implies always if none of always, never, or auto are -specified.

-column +core.fsyncMethod

- fill columns before rows + A value indicating the strategy Git will use to harden repository data + using fsync and related primitives.

-row -

- fill rows before columns +fsync uses the fsync() system call or platform equivalents.
-

-plain -

+ +

- show in one column +writeout-only issues pagecache writeback requests, but depending on the + filesystem and storage hardware, data added to the repository may not be + durable in the event of a system crash. This is the default mode on macOS.

Finally, these options can be combined with a layout option (defaults -to nodense):

-dense -: + +

- make unequal size columns to utilize more space +batch enables a mode that uses writeout-only flushes to stage multiple + updates in the disk writeback cache and then does a single full fsync of + a dummy file to trigger the disk cache flush at the end of the operation.
+
Currently batch mode only applies to loose-object files. Other repository +data is made durable as if fsync was specified. This mode is expected to +be as safe as fsync on macOS for repos stored on HFS+ or APFS filesystems +and on Windows for repos stored on NTFS or ReFS filesystems.
+
+

-nodense +core.fsyncObjectFiles

- make equal size columns + This boolean will enable fsync() when writing object files. + This setting is deprecated. Use core.fsync instead.

This setting affects data added to the Git repository in loose-object +form. When set to true, Git will issue an fsync or similar system call +to flush caches so that loose-objects remain consistent in the face +of a unclean system shutdown.

-column.branch +core.preloadIndex

- Specify whether to output branch listing in git branch in columns. - See column.ui for details. + Enable parallel index preload for operations like git diff

This can speed up operations like git diff and git status especially +on filesystems like NFS that have weak caching semantics and thus +relatively high IO latencies. When enabled, Git will do the +index comparison to the filesystem data in parallel, allowing +overlapping IO’s. Defaults to true.

-column.clean +core.unsetenvvars

- Specify the layout when listing items in git clean -i, which always - shows files and directories in columns. See column.ui for details. + Windows-only: comma-separated list of environment variables' + names that need to be unset before spawning any other process. + Defaults to PERL5LIB to account for the fact that Git for + Windows insists on using its own Perl interpreter.

-column.status +core.restrictinheritedhandles

- Specify whether to output untracked files in git status in columns. - See column.ui for details. + Windows-only: override whether spawned processes inherit only standard + file handles (stdin, stdout and stderr) or all handles. Can be + auto, true or false. Defaults to auto, which means true on + Windows 7 and later, and false on older Windows versions.

-column.tag +core.createObject

- Specify whether to output tag listings in git tag in columns. - See column.ui for details. + You can set this to link, in which case a hardlink followed by + a delete of the source are used to make sure that object creation + will not overwrite existing objects.

On some file system/operating system combinations, this is unreliable. +Set this config setting to rename there; However, This will remove the +check that makes sure that existing object files will not get overwritten.

-commit.cleanup +core.notesRef

- This setting overrides the default of the --cleanup option in - git commit. See git-commit(1) for details. Changing the - default can be useful when you always want to keep lines that begin - with the comment character # in your log message, in which case you - would do git config commit.cleanup whitespace (note that you will - have to remove the help lines that begin with # in the commit log - template yourself, if you do this). + When showing commit messages, also show notes which are stored in + the given ref. The ref must be fully qualified. If the given + ref does not exist, it is not an error but means that no + notes should be printed.

This setting defaults to "refs/notes/commits", and it can be overridden by +the GIT_NOTES_REF environment variable. See git-notes(1).

-commit.gpgSign +core.commitGraph

- A boolean to specify whether all commits should be GPG signed. - Use of this option when doing operations such as rebase can - result in a large number of commits being signed. It may be - convenient to use an agent to avoid typing your GPG passphrase - several times. + If true, then git will read the commit-graph file (if it exists) + to parse the graph structure of commits. Defaults to true. See + git-commit-graph(1) for more information.

-commit.status +core.useReplaceRefs

- A boolean to enable/disable inclusion of status information in the - commit message template when using an editor to prepare the commit - message. Defaults to true. + If set to false, behave as if the --no-replace-objects + option was given on the command line. See git(1) and + git-replace(1) for more information.

-commit.template +core.multiPackIndex

- Specify the pathname of a file to use as the template for - new commit messages. + Use the multi-pack-index file to track multiple packfiles using a + single index. See git-multi-pack-index(1) for more + information. Defaults to true.

-commit.verbose +core.sparseCheckout

- A boolean or int to specify the level of verbosity with git commit. - See git-commit(1). + Enable "sparse checkout" feature. See git-sparse-checkout(1) + for more information.

-commitGraph.generationVersion +core.sparseCheckoutCone

- Specifies the type of generation number version to use when writing - or reading the commit-graph file. If version 1 is specified, then - the corrected commit dates will not be written or read. Defaults to - 2. + Enables the "cone mode" of the sparse checkout feature. When the + sparse-checkout file contains a limited set of patterns, this + mode provides significant performance advantages. The "non-cone + mode" can be requested to allow specifying more flexible + patterns by setting this variable to false. See + git-sparse-checkout(1) for more information.

-commitGraph.maxNewFilters +core.abbrev

- Specifies the default value for the --max-new-filters option of git - commit-graph write (c.f., git-commit-graph(1)). + Set the length object names are abbreviated to. If + unspecified or set to "auto", an appropriate value is + computed based on the approximate number of packed objects + in your repository, which hopefully is enough for + abbreviated object names to stay unique for some time. + If set to "no", no abbreviation is made and the object names + are shown in their full length. + The minimum length is 4.

-commitGraph.readChangedPaths +core.maxTreeDepth

- If true, then git will use the changed-path Bloom filters in the - commit-graph file (if it exists, and they are present). Defaults to - true. See git-commit-graph(1) for more information. + The maximum depth Git is willing to recurse while traversing a + tree (e.g., "a/b/cde/f" has a depth of 4). This is a fail-safe + to allow Git to abort cleanly, and should not generally need to + be adjusted. The default is 4096.

@@ -4662,19 +4675,6 @@ credentialStore.lockTimeoutMS

-completion.commands -

- This is only used by git-completion.bash to add or remove - commands from the list of completed commands. Normally only - porcelain commands and a few select others are completed. You - can add more commands, separated by space, in this - variable. Prefixing the command with - will remove it from - the existing list. -

diff.autoRefreshIndex

@@ -5768,6 +5768,26 @@ bundle URI. If you modify the URI at fetch.bundleURI, then be sure remove the value for the fetch.bundleCreationToken value before fetching.

+filter.<driver>.clean +

+ The command which is used to convert the content of a worktree + file to a blob upon checkin. See gitattributes(5) for + details. +

+filter.<driver>.smudge +

+ The command which is used to convert the content of a blob + object to a worktree file upon checkout. See + gitattributes(5) for details. +

format.attach

@@ -6030,26 +6050,6 @@ format.noprefix

-filter.<driver>.clean -

- The command which is used to convert the content of a worktree - file to a blob upon checkin. See gitattributes(5) for - details. -

-filter.<driver>.smudge -

- The command which is used to convert the content of a blob - object to a worktree file upon checkout. See - gitattributes(5) for details. -

fsck.<msg-id>

@@ -6582,70 +6582,6 @@ gitweb.snapshot

-grep.lineNumber -

- If set to true, enable -n option by default. -

-grep.column -

- If set to true, enable the --column option by default. -

-grep.patternType -

- Set the default matching behavior. Using a value of basic, extended, - fixed, or perl will enable the --basic-regexp, --extended-regexp, - --fixed-strings, or --perl-regexp option accordingly, while the - value default will use the grep.extendedRegexp option to choose - between basic and extended. -

-grep.extendedRegexp -

- If set to true, enable --extended-regexp option by default. This - option is ignored when the grep.patternType option is set to a value - other than default. -

-grep.threads -

- Number of grep worker threads to use. If unset (or set to 0), Git will - use as many threads as the number of logical cores available. -

-grep.fullName -

- If set to true, enable --full-name option by default. -

-grep.fallbackToNoIndex -

- If set to true, fall back to git grep --no-index if git grep - is executed outside of a git repository. Defaults to false. -

gpg.program

@@ -6782,6 +6718,70 @@ gpg.ssh.revocationFile

+grep.lineNumber +

+ If set to true, enable -n option by default. +

+grep.column +

+ If set to true, enable the --column option by default. +

+grep.patternType +

+ Set the default matching behavior. Using a value of basic, extended, + fixed, or perl will enable the --basic-regexp, --extended-regexp, + --fixed-strings, or --perl-regexp option accordingly, while the + value default will use the grep.extendedRegexp option to choose + between basic and extended. +

+grep.extendedRegexp +

+ If set to true, enable --extended-regexp option by default. This + option is ignored when the grep.patternType option is set to a value + other than default. +

+grep.threads +

+ Number of grep worker threads to use. If unset (or set to 0), Git will + use as many threads as the number of logical cores available. +

+grep.fullName +

+ If set to true, enable --full-name option by default. +

+grep.fallbackToNoIndex +

+ If set to true, fall back to git grep --no-index if git grep + is executed outside of a git repository. Defaults to false. +

gui.commitMsgWidth

@@ -10825,6 +10825,36 @@ follows:

change as git gains new features.

+stash.showIncludeUntracked +

+ If this is set to true, the git stash show command will show + the untracked files of a stash entry. Defaults to false. See + the description of the show command in git-stash(1). +

+stash.showPatch +

+ If this is set to true, the git stash show command without an + option will show the stash entry in patch form. Defaults to false. + See the description of the show command in git-stash(1). +

+stash.showStat +

+ If this is set to true, the git stash show command without an + option will show a diffstat of the stash entry. Defaults to true. + See the description of the show command in git-stash(1). +

status.relativePaths

@@ -10966,36 +10996,6 @@ status.submoduleSummary

-stash.showIncludeUntracked -

- If this is set to true, the git stash show command will show - the untracked files of a stash entry. Defaults to false. See - the description of the show command in git-stash(1). -

-stash.showPatch -

- If this is set to true, the git stash show command without an - option will show the stash entry in patch form. Defaults to false. - See the description of the show command in git-stash(1). -

-stash.showStat -

- If this is set to true, the git stash show command without an - option will show a diffstat of the stash entry. Defaults to true. - See the description of the show command in git-stash(1). -

submodule.<name>.url

diff --git a/git-remote-helpers.html b/git-remote-helpers.html index 556df3e0a..567cbe963 100644 --- a/git-remote-helpers.html +++ b/git-remote-helpers.html @@ -735,7 +735,7 @@ asciidoc.install();

diff --git a/gitcli.html b/gitcli.html index 4ed8ec24f..66647ab79 100644 --- a/gitcli.html +++ b/gitcli.html @@ -843,12 +843,6 @@ scripting Git:

-It’s preferred to use the non-dashed form of Git commands, which means that - you should prefer git foo to git-foo. -
-
-
Splitting short options to separate words (prefer git foo -a -b to git foo -ab, the latter may not even work).
@@ -1052,7 +1046,7 @@ The two options can be specified together to ask a command to work

Last updated - 2023-10-23 14:43:46 PDT + 2024-03-11 15:39:49 PDT

diff --git a/gitcli.txt b/gitcli.txt index e5fac9432..7c709324b 100644 --- a/gitcli.txt +++ b/gitcli.txt @@ -81,9 +81,6 @@ you will. Here are the rules regarding the "flags" that you should follow when you are scripting Git: - * It's preferred to use the non-dashed form of Git commands, which means that - you should prefer `git foo` to `git-foo`. - * Splitting short options to separate words (prefer `git foo -a -b` to `git foo -ab`, the latter may not even work). diff --git a/howto/coordinate-embargoed-releases.html b/howto/coordinate-embargoed-releases.html index e1ec52da3..cbd4b2235 100644 --- a/howto/coordinate-embargoed-releases.html +++ b/howto/coordinate-embargoed-releases.html @@ -1038,7 +1038,7 @@ Thanks,

Last updated - 2024-03-07 16:01:38 PST + 2024-03-11 15:40:12 PDT

diff --git a/howto/keep-canonical-history-correct.html b/howto/keep-canonical-history-correct.html index 6153a193b..1bd38ac46 100644 --- a/howto/keep-canonical-history-correct.html +++ b/howto/keep-canonical-history-correct.html @@ -735,7 +735,7 @@ asciidoc.install();

Keep authoritative canonical history correct with git pull
-2024-03-07 +2024-03-11

@@ -939,7 +939,7 @@ tip of your master again and redo the two merges:

Last updated - 2024-03-07 16:01:38 PST + 2024-03-11 15:40:12 PDT

diff --git a/howto/maintain-git.html b/howto/maintain-git.html index 057981166..ed5f3a204 100644 --- a/howto/maintain-git.html +++ b/howto/maintain-git.html @@ -735,7 +735,7 @@ asciidoc.install();

How to maintain Git
-2024-03-07 +2024-03-11

@@ -1479,7 +1479,7 @@ $ git update-ref -d $mf/ai/topic

Last updated - 2024-03-07 16:01:38 PST + 2024-03-11 15:40:12 PDT

diff --git a/howto/new-command.html b/howto/new-command.html index 14cfe6723..c1087a7d4 100644 --- a/howto/new-command.html +++ b/howto/new-command.html @@ -735,7 +735,7 @@ asciidoc.install();

How to integrate new subcommands
-2024-03-07 +2024-03-11

@@ -864,7 +864,7 @@ letter [PATCH 0/n].

Last updated - 2024-03-07 16:01:37 PST + 2024-03-11 15:40:11 PDT

diff --git a/howto/rebase-from-internal-branch.html b/howto/rebase-from-internal-branch.html index ce7658a9e..8858ddc16 100644 --- a/howto/rebase-from-internal-branch.html +++ b/howto/rebase-from-internal-branch.html @@ -735,7 +735,7 @@ asciidoc.install();

How to rebase from an internal branch
-2024-03-07 +2024-03-11

@@ -896,7 +896,7 @@ the #1' commit.

Last updated - 2024-03-07 16:01:38 PST + 2024-03-11 15:40:12 PDT

diff --git a/howto/rebuild-from-update-hook.html b/howto/rebuild-from-update-hook.html index 26985f59b..c2edd3f8d 100644 --- a/howto/rebuild-from-update-hook.html +++ b/howto/rebuild-from-update-hook.html @@ -735,7 +735,7 @@ asciidoc.install();

How to rebuild from update hook
-2024-03-07 +2024-03-11

@@ -848,7 +848,7 @@ This is still crude and does not protect against simultaneous

Last updated - 2024-03-07 16:01:38 PST + 2024-03-11 15:40:12 PDT

diff --git a/howto/recover-corrupted-blob-object.html b/howto/recover-corrupted-blob-object.html index ab93292de..0cc4a979d 100644 --- a/howto/recover-corrupted-blob-object.html +++ b/howto/recover-corrupted-blob-object.html @@ -735,7 +735,7 @@ asciidoc.install();

How to recover a corrupted blob object
-2024-03-07 +2024-03-11

@@ -881,7 +881,7 @@ thing.

Last updated - 2024-03-07 16:01:38 PST + 2024-03-11 15:40:12 PDT

diff --git a/howto/recover-corrupted-object-harder.html b/howto/recover-corrupted-object-harder.html index a2a2cf786..574c457d4 100644 --- a/howto/recover-corrupted-object-harder.html +++ b/howto/recover-corrupted-object-harder.html @@ -735,7 +735,7 @@ asciidoc.install();

How to recover an object from scratch
-2024-03-07 +2024-03-11

@@ -1190,7 +1190,7 @@ int main(int argc, char **argv)

Last updated - 2024-03-07 16:01:38 PST + 2024-03-11 15:40:12 PDT

diff --git a/howto/revert-a-faulty-merge.html b/howto/revert-a-faulty-merge.html index 6b8cc2bfb..715f3ae23 100644 --- a/howto/revert-a-faulty-merge.html +++ b/howto/revert-a-faulty-merge.html @@ -735,7 +735,7 @@ asciidoc.install();

How to revert a faulty merge
-2024-03-07 +2024-03-11

@@ -1026,7 +1026,7 @@ P---o---o---M---x---x---W---x---M2

Last updated - 2024-03-07 16:01:38 PST + 2024-03-11 15:40:12 PDT

diff --git a/howto/revert-branch-rebase.html b/howto/revert-branch-rebase.html index c3dd3a491..0a11ac3c3 100644 --- a/howto/revert-branch-rebase.html +++ b/howto/revert-branch-rebase.html @@ -735,7 +735,7 @@ asciidoc.install();

How to revert an existing commit
-2024-03-07 +2024-03-11

@@ -908,7 +908,7 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f

Last updated - 2024-03-07 16:01:37 PST + 2024-03-11 15:40:11 PDT

diff --git a/howto/separating-topic-branches.html b/howto/separating-topic-branches.html index 5300c63c7..a596371dc 100644 --- a/howto/separating-topic-branches.html +++ b/howto/separating-topic-branches.html @@ -735,7 +735,7 @@ asciidoc.install();

How to separate topic branches
-2024-03-07 +2024-03-11

@@ -842,7 +842,7 @@ o---o"master"

Last updated - 2024-03-07 16:01:38 PST + 2024-03-11 15:40:12 PDT

diff --git a/howto/setup-git-server-over-http.html b/howto/setup-git-server-over-http.html index cf51b55fa..9624e19fd 100644 --- a/howto/setup-git-server-over-http.html +++ b/howto/setup-git-server-over-http.html @@ -735,7 +735,7 @@ asciidoc.install();

How to setup Git server over http
-2024-03-07 +2024-03-11

@@ -1072,7 +1072,7 @@ help diagnosing the problem, but removes security checks.

Last updated - 2024-03-07 16:01:38 PST + 2024-03-11 15:40:12 PDT

diff --git a/howto/update-hook-example.html b/howto/update-hook-example.html index 8fef612de..24e504308 100644 --- a/howto/update-hook-example.html +++ b/howto/update-hook-example.html @@ -735,7 +735,7 @@ asciidoc.install();

How to use the update hook
-2024-03-07 +2024-03-11

@@ -931,7 +931,7 @@ that JC can make non-fast-forward pushes on it.

Last updated - 2024-03-07 16:01:37 PST + 2024-03-11 15:40:11 PDT

diff --git a/howto/use-git-daemon.html b/howto/use-git-daemon.html index 1d34f456b..d0fc37ca9 100644 --- a/howto/use-git-daemon.html +++ b/howto/use-git-daemon.html @@ -735,7 +735,7 @@ asciidoc.install();

How to use git-daemon
-2024-03-07 +2024-03-11

@@ -792,7 +792,7 @@ a good practice to put the paths after a "--" separator.

Last updated - 2024-03-07 16:01:37 PST + 2024-03-11 15:40:11 PDT

diff --git a/howto/using-merge-subtree.html b/howto/using-merge-subtree.html index a3a6e039a..78a08094a 100644 --- a/howto/using-merge-subtree.html +++ b/howto/using-merge-subtree.html @@ -735,7 +735,7 @@ asciidoc.install();

How to use the subtree merge strategy
-2024-03-07 +2024-03-11

@@ -849,7 +849,7 @@ Please note that if the other project merges from you, then it will

Last updated - 2024-03-07 16:01:37 PST + 2024-03-11 15:40:11 PDT

diff --git a/howto/using-signed-tag-in-pull-request.html b/howto/using-signed-tag-in-pull-request.html index ed75319c6..3de19456e 100644 --- a/howto/using-signed-tag-in-pull-request.html +++ b/howto/using-signed-tag-in-pull-request.html @@ -735,7 +735,7 @@ asciidoc.install();

How to use a signed tag in pull requests
-2024-03-07 +2024-03-11

@@ -953,7 +953,7 @@ as part of the merge commit.

Last updated - 2024-03-07 16:01:37 PST + 2024-03-11 15:40:11 PDT

diff --git a/technical/api-error-handling.html b/technical/api-error-handling.html index 7657778c3..7ebc15f99 100644 --- a/technical/api-error-handling.html +++ b/technical/api-error-handling.html @@ -735,7 +735,7 @@ asciidoc.install();

Error reporting in git
-2024-03-07 +2024-03-11

diff --git a/technical/api-index.html b/technical/api-index.html index 6231df605..52f5acfb6 100644 --- a/technical/api-index.html +++ b/technical/api-index.html @@ -735,7 +735,7 @@ asciidoc.install();

Git API Documents
-2024-03-07 +2024-03-11

diff --git a/technical/api-merge.html b/technical/api-merge.html index c221d5e06..bf394b3bb 100644 --- a/technical/api-merge.html +++ b/technical/api-merge.html @@ -735,7 +735,7 @@ asciidoc.install();

merge API
-2024-03-07 +2024-03-11

diff --git a/technical/api-parse-options.html b/technical/api-parse-options.html index f58e04898..11f124e19 100644 --- a/technical/api-parse-options.html +++ b/technical/api-parse-options.html @@ -735,7 +735,7 @@ asciidoc.install();

parse-options API
-2024-03-07 +2024-03-11

diff --git a/technical/api-simple-ipc.html b/technical/api-simple-ipc.html index 57258d4de..0fce1778e 100644 --- a/technical/api-simple-ipc.html +++ b/technical/api-simple-ipc.html @@ -735,7 +735,7 @@ asciidoc.install();

Simple-IPC API
-2024-03-07 +2024-03-11

diff --git a/technical/api-trace2.html b/technical/api-trace2.html index e420edb8e..8823130f3 100644 --- a/technical/api-trace2.html +++ b/technical/api-trace2.html @@ -735,7 +735,7 @@ asciidoc.install();

Trace2 API
-2024-03-07 +2024-03-11

diff --git a/technical/bitmap-format.html b/technical/bitmap-format.html index 69e1ddd1a..efbd5995d 100644 --- a/technical/bitmap-format.html +++ b/technical/bitmap-format.html @@ -735,7 +735,7 @@ asciidoc.install();

GIT bitmap v1 format
-2024-03-07 +2024-03-11

diff --git a/technical/bundle-uri.html b/technical/bundle-uri.html index ea565247f..ca974c8c2 100644 --- a/technical/bundle-uri.html +++ b/technical/bundle-uri.html @@ -735,7 +735,7 @@ asciidoc.install();

Bundle URIs
-2024-03-07 +2024-03-11

diff --git a/technical/hash-function-transition.html b/technical/hash-function-transition.html index 6d60cbba2..2e6777c3d 100644 --- a/technical/hash-function-transition.html +++ b/technical/hash-function-transition.html @@ -735,7 +735,7 @@ asciidoc.install();

Git hash function transition
-2024-03-07 +2024-03-11

diff --git a/technical/long-running-process-protocol.html b/technical/long-running-process-protocol.html index f41dba74f..6d55b8f69 100644 --- a/technical/long-running-process-protocol.html +++ b/technical/long-running-process-protocol.html @@ -735,7 +735,7 @@ asciidoc.install();

Long-running process protocol
-2024-03-07 +2024-03-11

diff --git a/technical/multi-pack-index.html b/technical/multi-pack-index.html index a6c2d57c2..08cdbb2c0 100644 --- a/technical/multi-pack-index.html +++ b/technical/multi-pack-index.html @@ -735,7 +735,7 @@ asciidoc.install();

Multi-Pack-Index (MIDX) Design Notes
-2024-03-07 +2024-03-11

diff --git a/technical/pack-heuristics.html b/technical/pack-heuristics.html index f54d4dbc8..792b16dd5 100644 --- a/technical/pack-heuristics.html +++ b/technical/pack-heuristics.html @@ -735,7 +735,7 @@ asciidoc.install();

Concerning Git’s Packing Heuristics
-2024-03-07 +2024-03-11

diff --git a/technical/parallel-checkout.html b/technical/parallel-checkout.html index d4fcebd7c..8ca8da52c 100644 --- a/technical/parallel-checkout.html +++ b/technical/parallel-checkout.html @@ -735,7 +735,7 @@ asciidoc.install();

Parallel Checkout Design Notes
-2024-03-07 +2024-03-11

diff --git a/technical/partial-clone.html b/technical/partial-clone.html index 8149b89d8..298e4c0e6 100644 --- a/technical/partial-clone.html +++ b/technical/partial-clone.html @@ -735,7 +735,7 @@ asciidoc.install();

Partial Clone Design Notes
-2024-03-07 +2024-03-11

diff --git a/technical/racy-git.html b/technical/racy-git.html index 56e338119..285d31701 100644 --- a/technical/racy-git.html +++ b/technical/racy-git.html @@ -735,7 +735,7 @@ asciidoc.install();

Use of index and Racy Git problem
-2024-03-07 +2024-03-11

diff --git a/technical/scalar.html b/technical/scalar.html index ccc198a07..8cff6132e 100644 --- a/technical/scalar.html +++ b/technical/scalar.html @@ -735,7 +735,7 @@ asciidoc.install();

Scalar
-2024-03-07 +2024-03-11

diff --git a/technical/send-pack-pipeline.html b/technical/send-pack-pipeline.html index ca206fcde..5fd755c74 100644 --- a/technical/send-pack-pipeline.html +++ b/technical/send-pack-pipeline.html @@ -735,7 +735,7 @@ asciidoc.install();

Git-send-pack internals
-2024-03-07 +2024-03-11

diff --git a/technical/shallow.html b/technical/shallow.html index 35bb077ea..968915708 100644 --- a/technical/shallow.html +++ b/technical/shallow.html @@ -735,7 +735,7 @@ asciidoc.install();

Shallow commits
-2024-03-07 +2024-03-11

diff --git a/technical/trivial-merge.html b/technical/trivial-merge.html index 854559cb4..29187f9e9 100644 --- a/technical/trivial-merge.html +++ b/technical/trivial-merge.html @@ -735,7 +735,7 @@ asciidoc.install();

Trivial merge rules
-2024-03-07 +2024-03-11

diff --git a/technical/unit-tests.html b/technical/unit-tests.html index 1feee92ad..95371476d 100644 --- a/technical/unit-tests.html +++ b/technical/unit-tests.html @@ -735,7 +735,7 @@ asciidoc.install();

Unit Testing
-2024-03-07 +2024-03-11

diff --git a/user-manual.html b/user-manual.html index 2a8d4ff15..160a40be6 100644 --- a/user-manual.html +++ b/user-manual.html @@ -1,5 +1,5 @@ -Git User Manual
Git User Manual
Revision History
2024-03-07
Table of Contents
Introduction
1. Repositories and Branches
How to get a Git repository
How to check out a different version of a project
Understanding History: Commits
Understanding history: commits, parents, and reachability
Understanding history: History diagrams
Understanding history: What is a branch?
Manipulating branches
Examining an old version without creating a new branch
Examining branches from a remote repository
Naming branches, tags, and other references
Updating a repository with git fetch
Fetching branches from other repositories
2. Exploring Git history
How to use bisect to find a regression
Naming commits
Creating tags
Browsing revisions
Generating diffs
Viewing old file versions
Examples
Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content
3. Developing with Git
Telling Git your name
Creating a new repository
How to make a commit
Creating good commit messages
Ignoring files
How to merge
Resolving a merge
Getting conflict-resolution help during a merge
Undoing a merge
Fast-forward merges
Fixing mistakes
Fixing a mistake with a new commit
Fixing a mistake by rewriting history
Checking out an old version of a file
Temporarily setting aside work in progress
Ensuring good performance
Ensuring reliability
Checking the repository for corruption
Recovering lost changes
4. Sharing development with others
Getting updates with git pull
Submitting patches to a project
Importing patches to a project
Public Git repositories
Setting up a public repository
Exporting a Git repository via the Git protocol
Exporting a git repository via HTTP
Pushing changes to a public repository
What to do when a push fails
Setting up a shared repository
Allowing web browsing of a repository
How to get a Git repository with minimal history
Examples
Maintaining topic branches for a Linux subsystem maintainer
5. Rewriting history and maintaining patch series
Creating the perfect patch series
Keeping a patch series up to date using git rebase
Rewriting a single commit
Reordering or selecting from a patch series
Using interactive rebases
Other tools
Problems with rewriting history
Why bisecting merge commits can be harder than bisecting linear history
6. Advanced branch management
Fetching individual branches
git fetch and fast-forwards
Forcing git fetch to do non-fast-forward updates
Configuring remote-tracking branches
7. Git concepts
The Object Database
Commit Object
Tree Object
Blob Object
Trust
Tag Object
How Git stores objects efficiently: pack files
Dangling objects
Recovering from repository corruption
The index
8. Submodules
Pitfalls with submodules
9. Low-level Git operations
Object access and manipulation
The Workflow
working directory → index
index → object database
object database → index
index → working directory
Tying it all together
Examining the data
Merging multiple trees
Merging multiple trees, continued
10. Hacking Git
Object storage format
A birds-eye view of Git’s source code
11. Git Glossary
Git explained
A. Git Quick Reference
Creating a new repository
Managing branches
Exploring history
Making changes
Merging
Sharing your changes
Repository maintenance
B. Notes and todo list for this manual
Todo list
Introduction
Git is a fast distributed revision control system.
This manual is designed to be readable by someone with basic UNIX +Git User Manual
Git User Manual
Revision History
2024-03-11
Table of Contents
Introduction
1. Repositories and Branches
How to get a Git repository
How to check out a different version of a project
Understanding History: Commits
Understanding history: commits, parents, and reachability
Understanding history: History diagrams
Understanding history: What is a branch?
Manipulating branches
Examining an old version without creating a new branch
Examining branches from a remote repository
Naming branches, tags, and other references
Updating a repository with git fetch
Fetching branches from other repositories
2. Exploring Git history
How to use bisect to find a regression
Naming commits
Creating tags
Browsing revisions
Generating diffs
Viewing old file versions
Examples
Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content
3. Developing with Git
Telling Git your name
Creating a new repository
How to make a commit
Creating good commit messages
Ignoring files
How to merge
Resolving a merge
Getting conflict-resolution help during a merge
Undoing a merge
Fast-forward merges
Fixing mistakes
Fixing a mistake with a new commit
Fixing a mistake by rewriting history
Checking out an old version of a file
Temporarily setting aside work in progress
Ensuring good performance
Ensuring reliability
Checking the repository for corruption
Recovering lost changes
4. Sharing development with others
Getting updates with git pull
Submitting patches to a project
Importing patches to a project
Public Git repositories
Setting up a public repository
Exporting a Git repository via the Git protocol
Exporting a git repository via HTTP
Pushing changes to a public repository
What to do when a push fails
Setting up a shared repository
Allowing web browsing of a repository
How to get a Git repository with minimal history
Examples
Maintaining topic branches for a Linux subsystem maintainer
5. Rewriting history and maintaining patch series
Creating the perfect patch series
Keeping a patch series up to date using git rebase
Rewriting a single commit
Reordering or selecting from a patch series
Using interactive rebases
Other tools
Problems with rewriting history
Why bisecting merge commits can be harder than bisecting linear history
6. Advanced branch management
Fetching individual branches
git fetch and fast-forwards
Forcing git fetch to do non-fast-forward updates
Configuring remote-tracking branches
7. Git concepts
The Object Database
Commit Object
Tree Object
Blob Object
Trust
Tag Object
How Git stores objects efficiently: pack files
Dangling objects
Recovering from repository corruption
The index
8. Submodules
Pitfalls with submodules
9. Low-level Git operations
Object access and manipulation
The Workflow
working directory → index
index → object database
object database → index
index → working directory
Tying it all together
Examining the data
Merging multiple trees
Merging multiple trees, continued
10. Hacking Git
Object storage format
A birds-eye view of Git’s source code
11. Git Glossary
Git explained
A. Git Quick Reference
Creating a new repository
Managing branches
Exploring history
Making changes
Merging
Sharing your changes
Repository maintenance
B. Notes and todo list for this manual
Todo list
Introduction
Git is a fast distributed revision control system.
This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of Git.
Chapter 1, Repositories and Branches and Chapter 2, Exploring Git history explain how to fetch and study a project using git—read these chapters to learn how to build and test a particular version of a software project, search for -- cgit 1.2.3-korg

My First Contribution to the Git Project

My First Object Walk

Reviewing Patches in the Git Project

Submitting Patches

Tools for developing Git

Everyday Git With 20 Commands Or So

git-remote-helpers

Keep authoritative canonical history correct with git pull

How to maintain Git

How to integrate new subcommands

How to rebase from an internal branch

How to rebuild from update hook

How to recover a corrupted blob object

How to recover an object from scratch

How to revert a faulty merge

How to revert an existing commit

How to separate topic branches

How to setup Git server over http

How to use the update hook

How to use git-daemon

How to use the subtree merge strategy

How to use a signed tag in pull requests

Error reporting in git

Git API Documents

merge API

parse-options API

Simple-IPC API

Trace2 API

GIT bitmap v1 format

Bundle URIs

Git hash function transition

Long-running process protocol

Multi-Pack-Index (MIDX) Design Notes

Concerning Git’s Packing Heuristics

Parallel Checkout Design Notes

Partial Clone Design Notes

Use of index and Racy Git problem

Scalar

Git-send-pack internals

Shallow commits

Trivial merge rules

Unit Testing

Git User Manual

Introduction

Git User Manual

Introduction