neulab/tldr huggingface dataset:
mailmap.file The location of an augmenting mailmap file. The default mailmap, located in the root of the repository, is loaded first, then the mailmap file pointed to by this variable. The location of the mailmap file may be in a repository subdirectory, or somewhere outside of the repository itself. See git-shortlog(1) and git-blame(1).
mailmap.blob Like mailmap.file, but consider the value as a reference to a blob in the repository. If both mailmap.file and mailmap.blob are given, both are parsed, with entries from mailmap.file taking precedence. In a bare repository, this defaults to HEAD:.mailmap. In a non-bare repository, it defaults to empty.
maintenance.auto This boolean config option controls whether some commands run git maintenance run --auto after doing their normal work. Defaults to true.
maintenance.strategy This string config option provides a way to specify one of a few recommended schedules for background maintenance. This only affects which tasks are run during git maintenance run --schedule=X commands, provided no --task=<task> arguments are provided. Further, if a maintenance.<task>.schedule config value is set, then that value is used instead of the one provided by maintenance.strategy. The possible strategy strings are:
•   none: This default setting implies no task are run at any schedule.
•   incremental: This setting optimizes for performing small maintenance activities that do not delete any data. This does not schedule the gc task, but runs the prefetch and commit-graph tasks hourly, the loose-objects and incremental-repack tasks daily, and the pack-refs task weekly.
maintenance.<task>.enabled This boolean config option controls whether the maintenance task with name <task> is run when no --task option is specified to git maintenance run. These config values are ignored if a --task option exists. By default, only maintenance.gc.enabled is true.
maintenance.<task>.schedule This config option controls whether or not the given <task> runs during a git maintenance run --schedule=<frequency> command. The value must be one of "hourly", "daily", or "weekly".
maintenance.commit-graph.auto This integer config option controls how often the commit-graph task should be run as part of git maintenance run --auto. If zero, then the commit-graph task will not run with the --auto option. A negative value will force the task to run every time. Otherwise, a positive value implies the command should run when the number of reachable commits that are not in the commit-graph file is at least the value of maintenance.commit-graph.auto. The default value is 100.
maintenance.loose-objects.auto This integer config option controls how often the loose-objects task should be run as part of git maintenance run --auto. If zero, then the loose-objects task will not run with the --auto option. A negative value will force the task to run every time. Otherwise, a positive value implies the command should run when the number of loose objects is at least the value of maintenance.loose-objects.auto. The default value is 100.
maintenance.incremental-repack.auto This integer config option controls how often the incremental-repack task should be run as part of git maintenance run --auto. If zero, then the incremental-repack task will not run with the --auto option. A negative value will force the task to run every time. Otherwise, a positive value implies the command should run when the number of pack-files not in the multi-pack-index is at least the value of maintenance.incremental-repack.auto. The default value is 10.
man.viewer Specify the programs that may be used to display help in the man format. See git-help(1).
man.<tool>.cmd Specify the command to invoke the specified man viewer. The specified command is evaluated in shell with the man page passed as argument. (See git-help(1).)
man.<tool>.path Override the path for the given tool that may be used to display help in the man format. See git-help(1).
notes.mergeStrategy Which merge strategy to choose by default when resolving notes conflicts. Must be one of manual, ours, theirs, union, or cat_sort_uniq. Defaults to manual. See "NOTES MERGE STRATEGIES" section of git-notes(1) for more information on each strategy.
notes.<name>.mergeStrategy Which merge strategy to choose when doing a notes merge into refs/notes/<name>. This overrides the more general "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in git-notes(1) for more information on the available strategies.
notes.displayRef The (fully qualified) refname from which to show notes when showing commit messages. The value of this variable can be set to a glob, in which case notes from all matching refs will be shown. You may also specify this configuration variable several times. A warning will be issued for refs that do not exist, but a glob that does not match any refs is silently ignored.
This setting can be overridden with the GIT_NOTES_DISPLAY_REF environment variable, which must be a colon separated list of refs or globs.
The effective value of "core.notesRef" (possibly overridden by GIT_NOTES_REF) is also implicitly added to the list of refs to be displayed.
notes.rewrite.<command> When rewriting commits with <command> (currently amend or rebase) and this variable is set to true, Git automatically copies your notes from the original to the rewritten commit. Defaults to true, but see "notes.rewriteRef" below.
notes.rewriteMode When copying notes during a rewrite (see the "notes.rewrite.<command>" option), determines what to do if the target commit already has a note. Must be one of overwrite, concatenate, cat_sort_uniq, or ignore. Defaults to concatenate.
notes.rewriteRef When copying notes during a rewrite, specifies the (fully qualified) ref whose notes should be copied. The ref may be a glob, in which case notes in all matching refs will be copied. You may also specify this configuration several times.
Does not have a default value; you must configure this variable to enable note rewriting. Set it to refs/notes/commits to enable rewriting for the default commit notes.
This setting can be overridden with the GIT_NOTES_REWRITE_REF environment variable, which must be a colon separated list of refs or globs.
pack.window The size of the window used by git-pack-objects(1) when no window size is given on the command line. Defaults to 10.
pack.depth The maximum delta depth used by git-pack-objects(1) when no maximum depth is given on the command line. Defaults to 50. Maximum value is 4095.
pack.windowMemory The maximum size of memory that is consumed by each thread in git- pack-objects(1) for pack window memory when no limit is given on the command line. The value can be suffixed with "k", "m", or "g". When left unconfigured (or set explicitly to 0), there will be no limit.
pack.compression An integer -1..9, indicating the compression level for objects 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, the zlib default, which is "a default compromise between speed and compression (currently equivalent to level 6)."
Note that changing the compression level will not automatically recompress all existing objects. You can force recompression by passing the -F option to git-repack(1).
pack.allowPackReuse When true, and when reachability bitmaps are enabled, pack-objects will try to send parts of the bitmapped packfile verbatim. This can reduce memory and CPU usage to serve fetches, but might result in sending a slightly larger pack. Defaults to true.
pack.island An extended regular expression configuring a set of delta islands. See "DELTA ISLANDS" in git-pack-objects(1) for details.
pack.islandCore Specify an island name which gets to have its objects be packed first. This creates a kind of pseudo-pack at the front of one pack, so that the objects from the specified island are hopefully faster to copy into any pack that should be served to a user requesting these objects. In practice this means that the island specified should likely correspond to what is the most commonly cloned in the repo. See also "DELTA ISLANDS" in git-pack-objects(1).
pack.deltaCacheSize The maximum memory in bytes used for caching deltas in git-pack- objects(1) before writing them out to a pack. This cache is used to speed up the writing object phase by not having to recompute the final delta result once the best match for all objects is found. Repacking large repositories on machines which are tight with memory might be badly impacted by this though, especially if this cache pushes the system into swapping. A value of 0 means no limit. The smallest size of 1 byte may be used to virtually disable this cache. Defaults to 256 MiB.
pack.deltaCacheLimit The maximum size of a delta, that is cached in git-pack-objects(1). This cache is used to speed up the writing object phase by not having to recompute the final delta result once the best match for all objects is found. Defaults to 1000. Maximum value is 65535.
pack.threads Specifies the number of threads to spawn when searching for best delta matches. This requires that git-pack-objects(1) be compiled with pthreads otherwise this option is ignored with a warning. This is meant to reduce packing time on multiprocessor machines. The required amount of memory for the delta search window is however multiplied by the number of threads. Specifying 0 will cause Git to auto-detect the number of CPU’s and set the number of threads accordingly.
pack.indexVersion Specify the default pack index version. Valid values are 1 for legacy pack index used by Git versions prior to 1.5.2, and 2 for the new pack index with capabilities for packs larger than 4 GB as well as proper protection against the repacking of corrupted packs. Version 2 is the default. Note that version 2 is enforced and this config option ignored whenever the corresponding pack is larger than 2 GB.
If you have an old Git that does not understand the version 2 *.idx file, cloning or fetching over a non native protocol (e.g. "http") that will copy both *.pack file and corresponding *.idx file from the other side may give you a repository that cannot be accessed with your older version of Git. If the *.pack file is smaller than 2 GB, however, you can use git-index-pack(1) on the *.pack file to regenerate the *.idx file.
pack.packSizeLimit The maximum size of a pack. This setting only affects packing to a file when repacking, i.e. the git:// protocol is unaffected. It can be overridden by the --max-pack-size option of git-repack(1). Reaching this limit results in the creation of multiple packfiles.
Note that this option is rarely useful, and may result in a larger total on-disk size (because Git will not store deltas between packs), as well as worse runtime performance (object lookup within multiple packs is slower than a single pack, and optimizations like reachability bitmaps cannot cope with multiple packs).
If you need to actively run Git using smaller packfiles (e.g., because your filesystem does not support large files), this option may help. But if your goal is to transmit a packfile over a medium that supports limited sizes (e.g., removable media that cannot store the whole repository), you are likely better off creating a single large packfile and splitting it using a generic multi-volume archive tool (e.g., Unix split).
The minimum size allowed is limited to 1 MiB. The default is unlimited. Common unit suffixes of k, m, or g are supported.
pack.useBitmaps When true, git will use pack bitmaps (if available) when packing to stdout (e.g., during the server side of a fetch). Defaults to true. You should not generally need to turn this off unless you are debugging pack bitmaps.
pack.useSparse When true, git will default to using the --sparse option in git pack-objects when the --revs option is present. This algorithm only walks trees that appear in paths that introduce new objects. This can have significant performance benefits when computing a pack to send a small change. However, it is possible that extra objects are added to the pack-file if the included commits contain certain types of direct renames. Default is true.
pack.preferBitmapTips When selecting which commits will receive bitmaps, prefer a commit at the tip of any reference that is a suffix of any value of this configuration over any other commits in the "selection window".
Note that setting this configuration to refs/foo does not mean that the commits at the tips of refs/foo/bar and refs/foo/baz will necessarily be selected. This is because commits are selected for bitmaps from within a series of windows of variable length.
If a commit at the tip of any reference which is a suffix of any value of this configuration is seen in a window, it is immediately given preference over any other commit in that window.
pack.writeBitmaps (deprecated) This is a deprecated synonym for repack.writeBitmaps.
pack.writeBitmapHashCache When true, git will include a "hash cache" section in the bitmap index (if one is written). This cache can be used to feed git’s delta heuristics, potentially leading to better deltas between bitmapped and non-bitmapped objects (e.g., when serving a fetch between an older, bitmapped pack and objects that have been pushed since the last gc). The downside is that it consumes 4 bytes per object of disk space. Defaults to true.
When writing a multi-pack reachability bitmap, no new namehashes are computed; instead, any namehashes stored in an existing bitmap are permuted into their appropriate location when writing a new bitmap.
pack.writeReverseIndex When true, git will write a corresponding .rev file (see: Documentation/technical/pack-format.txt[3]) for each new packfile that it writes in all places except for git-fast-import(1) and in the bulk checkin mechanism. Defaults to false.
pager.<cmd> If the value is boolean, turns on or off pagination of the output of a particular Git subcommand when writing to a tty. Otherwise, turns on pagination for the subcommand using the pager specified by the value of pager.<cmd>. If --paginate or --no-pager is specified on the command line, it takes precedence over this option. To disable pagination for all commands, set core.pager or GIT_PAGER to cat.
pretty.<name> Alias for a --pretty= format string, as specified in git-log(1). Any aliases defined here can be used just as the built-in pretty formats could. For example, running git config pretty.changelog "format:* %H %s" would cause the invocation git log --pretty=changelog to be equivalent to running git log "--pretty=format:* %H %s". Note that an alias with the same name as a built-in format will be silently ignored.
protocol.allow If set, provide a user defined default policy for all protocols which don’t explicitly have a policy (protocol.<name>.allow). By default, if unset, known-safe protocols (http, https, git, ssh, file) have a default policy of always, known-dangerous protocols (ext) have a default policy of never, and all other protocols have a default policy of user. Supported policies:
•   always - protocol is always able to be used.
•   never - protocol is never able to be used.
•   user - protocol is only able to be used when GIT_PROTOCOL_FROM_USER is either unset or has a value of 1. This policy should be used when you want a protocol to be directly usable by the user but don’t want it used by commands which execute clone/fetch/push commands without user input, e.g. recursive submodule initialization.
protocol.<name>.allow Set a policy to be used by protocol <name> with clone/fetch/push commands. See protocol.allow above for the available policies.
The protocol names currently used by git are:
•   file: any local file-based path (including file:// URLs, or local paths)
•   git: the anonymous git protocol over a direct TCP connection (or proxy, if configured)
•   ssh: git over ssh (including host:path syntax, ssh://, etc).
•   http: git over http, both "smart http" and "dumb http". Note that this does not include https; if you want to configure both, you must do so individually.
•   any external helpers are named by their protocol (e.g., use hg to allow the git-remote-hg helper)
protocol.version If set, clients will attempt to communicate with a server using the specified protocol version. If the server does not support it, communication falls back to version 0. If unset, the default is 2. Supported versions:
•   0 - the original wire protocol.
•   1 - the original wire protocol with the addition of a version string in the initial response from the server.
•   2 - wire protocol version 2[4].
pull.ff By default, Git does not create an extra merge commit when merging a commit that is a descendant of the current commit. Instead, the tip of the current branch is fast-forwarded. When set to false, this variable tells Git to create an extra merge commit in such a case (equivalent to giving the --no-ff option from the command line). When set to only, only such fast-forward merges are allowed (equivalent to giving the --ff-only option from the command line). This setting overrides merge.ff when pulling.
pull.rebase When true, rebase branches on top of the fetched branch, instead of merging the default branch from the default remote when "git pull" is run. See "branch.<name>.rebase" for setting this on a per-branch basis.
pull.octopus The default merge strategy to use when pulling multiple branches at once.
pull.twohead The default merge strategy to use when pulling a single branch.
push.default Defines the action git push should take if no refspec is given (whether from the command-line, config, or elsewhere). Different values are well-suited for specific workflows; for instance, in a purely central workflow (i.e. the fetch source is equal to the push destination), upstream is probably what you want. Possible values are:
•   nothing - do not push anything (error out) unless a refspec is given. This is primarily meant for people who want to avoid mistakes by always being explicit.
•   current - push the current branch to update a branch with the same name on the receiving end. Works in both central and non-central workflows.
•   upstream - push the current branch back to the branch whose changes are usually integrated into the current branch (which is called @{upstream}). This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e. central workflow).
•   tracking - This is a deprecated synonym for upstream.
•   simple - pushes the current branch with the same name on the remote.
If you are working on a centralized workflow (pushing to the same repository you pull from, which is typically origin), then you need to configure an upstream branch with the same name.
This mode is the default since Git 2.0, and is the safest option suited for beginners.
•   matching - push all branches having the same name on both ends. This makes the repository you are pushing to remember the set of branches that will be pushed out (e.g. if you always push maint and master there and no other branches, the repository you push to will have these two branches, and your local maint and master will be pushed there).
To use this mode effectively, you have to make sure all the branches you would push out are ready to be pushed out before running git push, as the whole point of this mode is to allow you to push all of the branches in one go. If you usually finish work on only one branch and push out the result, while other branches are unfinished, this mode is not for you. Also this mode is not suitable for pushing into a shared central repository, as other people may add new branches there, or update the tip of existing branches outside your control.
This used to be the default, but not since Git 2.0 (simple is the new default).
push.followTags If set to true enable --follow-tags option by default. You may override this configuration at time of push by specifying --no-follow-tags.
push.gpgSign May be set to a boolean value, or the string if-asked. A true value causes all pushes to be GPG signed, as if --signed is passed to git- push(1). The string if-asked causes pushes to be signed if the server supports it, as if --signed=if-asked is passed to git push. A false value may override a value from a lower-priority config file. An explicit command-line flag always overrides this config option.
push.pushOption When no --push-option=<option> argument is given from the command line, git push behaves as if each <value> of this variable is given as --push-option=<value>.
This is a multi-valued variable, and an empty value can be used in a higher priority configuration file (e.g.  .git/config in a repository) to clear the values inherited from a lower priority configuration files (e.g.  $HOME/.gitconfig).
/etc/gitconfig push.pushoption = a push.pushoption = b
~/.gitconfig push.pushoption = c
repo/.git/config push.pushoption = push.pushoption = b
This will result in only b (a and c are cleared).
push.recurseSubmodules Make sure all submodule commits used by the revisions to be pushed are available on a remote-tracking branch. If the value is check then Git will verify that all submodule commits that changed in the revisions to be pushed are available on at least one remote of the submodule. If any commits are missing, the push will be aborted and exit with non-zero status. If the value is on-demand then all submodules that changed in the revisions to be pushed will be pushed. If on-demand was not able to push all necessary revisions it will also be aborted and exit with non-zero status. If the value is no then default behavior of ignoring submodules when pushing is retained. You may override this configuration at time of push by specifying --recurse-submodules=check|on-demand|no. If not set, no is used by default, unless submodule.recurse is set (in which case a true value means on-demand).
push.useForceIfIncludes If set to "true", it is equivalent to specifying --force-if-includes as an option to git-push(1) in the command line. Adding --no-force-if-includes at the time of push overrides this configuration setting.
push.negotiate If set to "true", attempt to reduce the size of the packfile sent by rounds of negotiation in which the client and the server attempt to find commits in common. If "false", Git will rely solely on the server’s ref advertisement to find commits in common.
receive.advertiseAtomic By default, git-receive-pack will advertise the atomic push capability to its clients. If you don’t want to advertise this capability, set this variable to false.
receive.advertisePushOptions When set to true, git-receive-pack will advertise the push options capability to its clients. False by default.
receive.autogc By default, git-receive-pack will run "git-gc --auto" after receiving data from git-push and updating refs. You can stop it by setting this variable to false.
receive.certNonceSeed By setting this variable to a string, git receive-pack will accept a git push --signed and verifies it by using a "nonce" protected by HMAC using this string as a secret key.
receive.certNonceSlop When a git push --signed sent a push certificate with a "nonce" that was issued by a receive-pack serving the same repository within this many seconds, export the "nonce" found in the certificate to GIT_PUSH_CERT_NONCE to the hooks (instead of what the receive-pack asked the sending side to include). This may allow writing checks in pre-receive and post-receive a bit easier. Instead of checking GIT_PUSH_CERT_NONCE_SLOP environment variable that records by how many seconds the nonce is stale to decide if they want to accept the certificate, they only can check GIT_PUSH_CERT_NONCE_STATUS is OK.
receive.fsckObjects If it is set to true, git-receive-pack will check all received objects. See transfer.fsckObjects for what’s checked. Defaults to false. If not set, the value of transfer.fsckObjects is used instead.
receive.fsck.<msg-id> Acts like fsck.<msg-id>, but is used by git-receive-pack(1) instead of git-fsck(1). See the fsck.<msg-id> documentation for details.
receive.fsck.skipList Acts like fsck.skipList, but is used by git-receive-pack(1) instead of git-fsck(1). See the fsck.skipList documentation for details.
receive.keepAlive After receiving the pack from the client, receive-pack may produce no output (if --quiet was specified) while processing the pack, causing some networks to drop the TCP connection. With this option set, if receive-pack does not transmit any data in this phase for receive.keepAlive seconds, it will send a short keepalive packet. The default is 5 seconds; set to 0 to disable keepalives entirely.
receive.unpackLimit If the number of objects received in a push is below this limit then the objects will be unpacked into loose object files. However if the number of received objects equals or exceeds this limit then the received pack will be stored as a pack, after adding any missing delta bases. Storing the pack from a push can make the push operation complete faster, especially on slow filesystems. If not set, the value of transfer.unpackLimit is used instead.
receive.maxInputSize If the size of the incoming pack stream is larger than this limit, then git-receive-pack will error out, instead of accepting the pack file. If not set or set to 0, then the size is unlimited.
receive.denyDeletes If set to true, git-receive-pack will deny a ref update that deletes the ref. Use this to prevent such a ref deletion via a push.
receive.denyDeleteCurrent If set to true, git-receive-pack will deny a ref update that deletes the currently checked out branch of a non-bare repository.
receive.denyCurrentBranch If set to true or "refuse", git-receive-pack will deny a ref update to the currently checked out branch of a non-bare repository. Such a push is potentially dangerous because it brings the HEAD out of sync with the index and working tree. If set to "warn", print a warning of such a push to stderr, but allow the push to proceed. If set to false or "ignore", allow such pushes with no message. Defaults to "refuse".
Another option is "updateInstead" which will update the working tree if pushing into the current branch. This option is intended for synchronizing working directories when one side is not easily accessible via interactive ssh (e.g. a live web site, hence the requirement that the working directory be clean). This mode also comes in handy when developing inside a VM to test and fix code on different Operating Systems.
By default, "updateInstead" will refuse the push if the working tree or the index have any difference from the HEAD, but the push-to-checkout hook can be used to customize this. See githooks(5).
receive.denyNonFastForwards If set to true, git-receive-pack will deny a ref update which is not a fast-forward. Use this to prevent such an update via a push, even if that push is forced. This configuration variable is set when initializing a shared repository.
receive.hideRefs This variable is the same as transfer.hideRefs, but applies only to receive-pack (and so affects pushes, but not fetches). An attempt to update or delete a hidden ref by git push is rejected.
receive.procReceiveRefs This is a multi-valued variable that defines reference prefixes to match the commands in receive-pack. Commands matching the prefixes will be executed by an external hook "proc-receive", instead of the internal execute_commands function. If this variable is not defined, the "proc-receive" hook will never be used, and all commands will be executed by the internal execute_commands function.
For example, if this variable is set to "refs/for", pushing to reference such as "refs/for/master" will not create or update a reference named "refs/for/master", but may create or update a pull request directly by running the hook "proc-receive".
Optional modifiers can be provided in the beginning of the value to filter commands for specific actions: create (a), modify (m), delete (d). A !  can be included in the modifiers to negate the reference prefix entry. E.g.:
git config --system --add receive.procReceiveRefs ad:refs/heads git config --system --add receive.procReceiveRefs !:refs/heads
receive.updateServerInfo If set to true, git-receive-pack will run git-update-server-info after receiving data from git-push and updating refs.
receive.shallowUpdate If set to true, .git/shallow can be updated when new refs require new shallow roots. Otherwise those refs are rejected.
remote.pushDefault The remote to push to by default. Overrides branch.<name>.remote for all branches, and is overridden by branch.<name>.pushRemote for specific branches.
remote.<name>.url The URL of a remote repository. See git-fetch(1) or git-push(1).
remote.<name>.pushurl The push URL of a remote repository. See git-push(1).
remote.<name>.proxy For remotes that require curl (http, https and ftp), the URL to the proxy to use for that remote. Set to the empty string to disable proxying for that remote.
remote.<name>.proxyAuthMethod For remotes that require curl (http, https and ftp), the method to use for authenticating against the proxy in use (probably set in remote.<name>.proxy). See http.proxyAuthMethod.
remote.<name>.fetch The default set of "refspec" for git-fetch(1). See git-fetch(1).
remote.<name>.push The default set of "refspec" for git-push(1). See git-push(1).
remote.<name>.mirror If true, pushing to this remote will automatically behave as if the --mirror option was given on the command line.
remote.<name>.skipDefaultUpdate If true, this remote will be skipped by default when updating using git-fetch(1) or the update subcommand of git-remote(1).
remote.<name>.skipFetchAll If true, this remote will be skipped by default when updating using git-fetch(1) or the update subcommand of git-remote(1).
remote.<name>.receivepack The default program to execute on the remote side when pushing. See option --receive-pack of git-push(1).
remote.<name>.uploadpack The default program to execute on the remote side when fetching. See option --upload-pack of git-fetch-pack(1).
remote.<name>.tagOpt Setting this value to --no-tags disables automatic tag following when fetching from remote <name>. Setting it to --tags will fetch every tag from remote <name>, even if they are not reachable from remote branch heads. Passing these flags directly to git-fetch(1) can override this setting. See options --tags and --no-tags of git- fetch(1).
remote.<name>.vcs Setting this to a value <vcs> will cause Git to interact with the remote with the git-remote-<vcs> helper.
remote.<name>.prune When set to true, fetching from this remote by default will also remove any remote-tracking references that no longer exist on the remote (as if the --prune option was given on the command line). Overrides fetch.prune settings, if any.
remote.<name>.pruneTags When set to true, fetching from this remote by default will also remove any local tags that no longer exist on the remote if pruning is activated in general via remote.<name>.prune, fetch.prune or --prune. Overrides fetch.pruneTags settings, if any.
See also remote.<name>.prune and the PRUNING section of git-fetch(1).
remote.<name>.promisor When set to true, this remote will be used to fetch promisor objects.
remote.<name>.partialclonefilter The filter that will be applied when fetching from this promisor remote.
remotes.<group> The list of remotes which are fetched by "git remote update <group>". See git-remote(1).
repack.useDeltaBaseOffset By default, git-repack(1) creates packs that use delta-base offset. If you need to share your repository with Git older than version 1.4.4, either directly or via a dumb protocol such as http, then you need to set this option to "false" and repack. Access from old Git versions over the native protocol are unaffected by this option.
repack.packKeptObjects If set to true, makes git repack act as if --pack-kept-objects was passed. See git-repack(1) for details. Defaults to false normally, but true if a bitmap index is being written (either via --write-bitmap-index or repack.writeBitmaps).
repack.useDeltaIslands If set to true, makes git repack act as if --delta-islands was passed. Defaults to false.
repack.writeBitmaps When true, git will write a bitmap index when packing all objects to disk (e.g., when git repack -a is run). This index can speed up the "counting objects" phase of subsequent packs created for clones and fetches, at the cost of some disk space and extra time spent on the initial repack. This has no effect if multiple packfiles are created. Defaults to true on bare repos, false otherwise.
rerere.autoUpdate When set to true, git-rerere updates the index with the resulting contents after it cleanly resolves conflicts using previously recorded resolution. Defaults to false.
rerere.enabled Activate recording of resolved conflicts, so that identical conflict hunks can be resolved automatically, should they be encountered again. By default, git-rerere(1) is enabled if there is an rr-cache directory under the $GIT_DIR, e.g. if "rerere" was previously used in the repository.
reset.quiet When set to true, git reset will default to the --quiet option.
sendemail.identity A configuration identity. When given, causes values in the sendemail.<identity> subsection to take precedence over values in the sendemail section. The default identity is the value of sendemail.identity.
sendemail.smtpEncryption See git-send-email(1) for description. Note that this setting is not subject to the identity mechanism.
sendemail.smtpsslcertpath Path to ca-certificates (either a directory or a single file). Set it to an empty string to disable certificate verification.
sendemail.<identity>.* Identity-specific versions of the sendemail.*  parameters found below, taking precedence over those when this identity is selected, through either the command-line or sendemail.identity.
sendemail.aliasesFile, sendemail.aliasFileType, sendemail.annotate, sendemail.bcc, sendemail.cc, sendemail.ccCmd, sendemail.chainReplyTo, sendemail.confirm, sendemail.envelopeSender, sendemail.from, sendemail.multiEdit, sendemail.signedoffbycc, sendemail.smtpPass, sendemail.suppresscc, sendemail.suppressFrom, sendemail.to, sendemail.tocmd, sendemail.smtpDomain, sendemail.smtpServer, sendemail.smtpServerPort, sendemail.smtpServerOption, sendemail.smtpUser, sendemail.thread, sendemail.transferEncoding, sendemail.validate, sendemail.xmailer See git-send-email(1) for description.
sendemail.signedoffcc (deprecated) Deprecated alias for sendemail.signedoffbycc.
sendemail.smtpBatchSize Number of messages to be sent per connection, after that a relogin will happen. If the value is 0 or undefined, send all messages in one connection. See also the --batch-size option of git-send-email(1).
sendemail.smtpReloginDelay Seconds wait before reconnecting to smtp server. See also the --relogin-delay option of git-send-email(1).
sendemail.forbidSendmailVariables To avoid common misconfiguration mistakes, git-send-email(1) will abort with a warning if any configuration options for "sendmail" exist. Set this variable to bypass the check.
showBranch.default The default set of branches for git-show-branch(1). See git-show- branch(1).
splitIndex.maxPercentChange When the split index feature is used, this specifies the percent of entries the split index can contain compared to the total number of entries in both the split index and the shared index before a new shared index is written. The value should be between 0 and 100. If the value is 0 then a new shared index is always written, if it is 100 a new shared index is never written. By default the value is 20, so a new shared index is written if the number of entries in the split index would be greater than 20 percent of the total number of entries. See git-update-index(1).
splitIndex.sharedIndexExpire When the split index feature is used, shared index files that were not modified since the time this variable specifies will be removed when a new shared index file is created. The value "now" expires all entries immediately, and "never" suppresses expiration altogether. The default value is "2.weeks.ago". Note that a shared index file is considered modified (for the purpose of expiration) each time a new split-index file is either created based on it or read from it. See git-update-index(1).
ssh.variant By default, Git determines the command line arguments to use based on the basename of the configured SSH command (configured using the environment variable GIT_SSH or GIT_SSH_COMMAND or the config setting core.sshCommand). If the basename is unrecognized, Git will attempt to detect support of OpenSSH options by first invoking the configured SSH command with the -G (print configuration) option and will subsequently use OpenSSH options (if that is successful) or no options besides the host and remote command (if it fails).
The config variable ssh.variant can be set to override this detection. Valid values are ssh (to use OpenSSH options), plink, putty, tortoiseplink, simple (no options except the host and remote command). The default auto-detection can be explicitly requested using the value auto. Any other value is treated as ssh. This setting can also be overridden via the environment variable GIT_SSH_VARIANT.
The current command-line parameters used for each variant are as follows:
•   ssh - [-p port] [-4] [-6] [-o option] [username@]host command
•   simple - [username@]host command
•   plink or putty - [-P port] [-4] [-6] [username@]host command
•   tortoiseplink - [-P port] [-4] [-6] -batch [username@]host command
Except for the simple variant, command-line parameters are likely to change as git gains new features.
status.relativePaths By default, git-status(1) shows paths relative to the current directory. Setting this variable to false shows paths relative to the repository root (this was the default for Git prior to v1.5.4).
status.short Set to true to enable --short by default in git-status(1). The option --no-short takes precedence over this variable.
status.branch Set to true to enable --branch by default in git-status(1). The option --no-branch takes precedence over this variable.
status.aheadBehind Set to true to enable --ahead-behind and false to enable --no-ahead-behind by default in git-status(1) for non-porcelain status formats. Defaults to true.
status.displayCommentPrefix If set to true, git-status(1) will insert a comment prefix before each output line (starting with core.commentChar, i.e.  # by default). This was the behavior of git-status(1) in Git 1.8.4 and previous. Defaults to false.
status.renameLimit The number of files to consider when performing rename detection in git-status(1) and git-commit(1). Defaults to the value of diff.renameLimit.
status.renames Whether and how Git detects renames in git-status(1) and git- commit(1) . If set to "false", rename detection is disabled. If set to "true", basic rename detection is enabled. If set to "copies" or "copy", Git will detect copies, as well. Defaults to the value of diff.renames.
status.showStash If set to true, git-status(1) will display the number of entries currently stashed away. Defaults to false.
status.showUntrackedFiles By default, git-status(1) and git-commit(1) show files which are not currently tracked by Git. Directories which contain only untracked files, are shown with the directory name only. Showing untracked files means that Git needs to lstat() all the files in the whole repository, which might be slow on some systems. So, this variable controls how the commands displays the untracked files. Possible values are:
•   normal - Show untracked files and directories.
•   all - Show also individual files in untracked directories.
If this variable is not specified, it defaults to normal. This variable can be overridden with the -u|--untracked-files option of git-status(1) and git-commit(1).
status.submoduleSummary Defaults to false. If this is set to a non zero number or true (identical to -1 or an unlimited number), the submodule summary will be enabled and a summary of commits for modified submodules will be shown (see --summary-limit option of git-submodule(1)). Please note that the summary output command will be suppressed for all submodules when diff.ignoreSubmodules is set to all or only for those submodules where submodule.<name>.ignore=all. The only exception to that rule is that status and commit will show staged submodule changes. To also view the summary for ignored submodules you can either use the --ignore-submodules=dirty command-line option or the git submodule summary command, which shows a similar output but does not honor these settings.
stash.useBuiltin Unused configuration variable. Used in Git versions 2.22 to 2.26 as an escape hatch to enable the legacy shellscript implementation of stash. Now the built-in rewrite of it in C is always used. Setting this will emit a warning, to alert any remaining users that setting this now does nothing.
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 description of 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 description of show command in git-stash(1).
stash.showStat If this is set to true, the git stash show command without an option will show diffstat of the stash entry. Defaults to true. See description of show command in git-stash(1).
submodule.<name>.url The URL for a submodule. This variable is copied from the .gitmodules file to the git config via git submodule init. The user can change the configured URL before obtaining the submodule via git submodule update. If neither submodule.<name>.active or submodule.active are set, the presence of this variable is used as a fallback to indicate whether the submodule is of interest to git commands. See git- submodule(1) and gitmodules(5) for details.
submodule.<name>.update The method by which a submodule is updated by git submodule update, which is the only affected command, others such as git checkout --recurse-submodules are unaffected. It exists for historical reasons, when git submodule was the only command to interact with submodules; settings like submodule.active and pull.rebase are more specific. It is populated by git submodule init from the gitmodules(5) file. See description of update command in git- submodule(1).
submodule.<name>.branch The remote branch name for a submodule, used by git submodule update --remote. Set this option to override the value found in the .gitmodules file. See git-submodule(1) and gitmodules(5) for details.
submodule.<name>.fetchRecurseSubmodules This option can be used to control recursive fetching of this submodule. It can be overridden by using the --[no-]recurse-submodules command-line option to "git fetch" and "git pull". This setting will override that from in the gitmodules(5) file.
submodule.<name>.ignore Defines under what circumstances "git status" and the diff family show a submodule as modified. When set to "all", it will never be considered modified (but it will nonetheless show up in the output of status and commit when it has been staged), "dirty" will ignore all changes to the submodules work tree and takes only differences between the HEAD of the submodule and the commit recorded in the superproject into account. "untracked" will additionally let submodules with modified tracked files in their work tree show up. Using "none" (the default when this option is not set) also shows submodules that have untracked files in their work tree as changed. This setting overrides any setting made in .gitmodules for this submodule, both settings can be overridden on the command line by using the "--ignore-submodules" option. The git submodule commands are not affected by this setting.
submodule.<name>.active Boolean value indicating if the submodule is of interest to git commands. This config option takes precedence over the submodule.active config option. See gitsubmodules(7) for details.
submodule.active A repeated field which contains a pathspec used to match against a submodule’s path to determine if the submodule is of interest to git commands. See gitsubmodules(7) for details.
submodule.recurse A boolean indicating if commands should enable the --recurse-submodules option by default. Applies to all commands that support this option (checkout, fetch, grep, pull, push, read-tree, reset, restore and switch) except clone and ls-files. Defaults to false. When set to true, it can be deactivated via the --no-recurse-submodules option. Note that some Git commands lacking this option may call some of the above commands affected by submodule.recurse; for instance git remote update will call git fetch but does not have a --no-recurse-submodules option. For these commands a workaround is to temporarily change the configuration value by using git -c submodule.recurse=0.
submodule.fetchJobs Specifies how many submodules are fetched/cloned at the same time. A positive integer allows up to that number of submodules fetched in parallel. A value of 0 will give some reasonable default. If unset, it defaults to 1.
submodule.alternateLocation Specifies how the submodules obtain alternates when submodules are cloned. Possible values are no, superproject. By default no is assumed, which doesn’t add references. When the value is set to superproject the submodule to be cloned computes its alternates location relative to the superprojects alternate.
submodule.alternateErrorStrategy Specifies how to treat errors with the alternates for a submodule as computed via submodule.alternateLocation. Possible values are ignore, info, die. Default is die. Note that if set to ignore or info, and if there is an error with the computed alternate, the clone proceeds as if no alternate was specified.
tag.forceSignAnnotated A boolean to specify whether annotated tags created should be GPG signed. If --annotate is specified on the command line, it takes precedence over this option.
tag.sort This variable controls the sort ordering of tags when displayed by git-tag(1). Without the "--sort=<value>" option provided, the value of this variable will be used as the default.
tag.gpgSign A boolean to specify whether all tags should be GPG signed. Use of this option when running in an automated script can result in a large number of tags being signed. It is therefore convenient to use an agent to avoid typing your gpg passphrase several times. Note that this option doesn’t affect tag signing behavior enabled by "-u <keyid>" or "--local-user=<keyid>" options.
tar.umask This variable can be used to restrict the permission bits of tar archive entries. The default is 0002, which turns off the world write bit. The special value "user" indicates that the archiving user’s umask will be used instead. See umask(2) and git-archive(1).
Trace2 config settings are only read from the system and global config files; repository local and worktree config files and -c command line arguments are not respected.
trace2.normalTarget This variable controls the normal target destination. It may be overridden by the GIT_TRACE2 environment variable. The following table shows possible values.
trace2.perfTarget This variable controls the performance target destination. It may be overridden by the GIT_TRACE2_PERF environment variable. The following table shows possible values.
trace2.eventTarget This variable controls the event target destination. It may be overridden by the GIT_TRACE2_EVENT environment variable. The following table shows possible values.
•   0 or false - Disables the target.
•   1 or true - Writes to STDERR.
•   [2-9] - Writes to the already opened file descriptor.
•   <absolute-pathname> - Writes to the file in append mode. If the target already exists and is a directory, the traces will be written to files (one per process) underneath the given directory.
•   af_unix:[<socket_type>:]<absolute-pathname> - Write to a Unix DomainSocket (on platforms that support them). Socket type can be either stream or dgram; if omitted Git will try both.
trace2.normalBrief Boolean. When true time, filename, and line fields are omitted from normal output. May be overridden by the GIT_TRACE2_BRIEF environment variable. Defaults to false.
trace2.perfBrief Boolean. When true time, filename, and line fields are omitted from PERF output. May be overridden by the GIT_TRACE2_PERF_BRIEF environment variable. Defaults to false.
trace2.eventBrief Boolean. When true time, filename, and line fields are omitted from event output. May be overridden by the GIT_TRACE2_EVENT_BRIEF environment variable. Defaults to false.