4 The Git configuration file contains a number of variables that affect
5 the Git commands' behavior. The `.git/config` file in each repository
6 is used to store the configuration for that repository, and
7 `$HOME/.gitconfig` is used to store a per-user configuration as
8 fallback values for the `.git/config` file. The file `/etc/gitconfig`
9 can be used to store a system-wide default configuration.
11 The configuration variables are used by both the Git plumbing
12 and the porcelains. The variables are divided into sections, wherein
13 the fully qualified variable name of the variable itself is the last
14 dot-separated segment and the section name is everything before the last
15 dot. The variable names are case-insensitive, allow only alphanumeric
16 characters and `-`, and must start with an alphabetic character. Some
17 variables may appear multiple times; we say then that the variable is
23 The syntax is fairly flexible and permissive; whitespaces are mostly
24 ignored. The '#' and ';' characters begin comments to the end of line,
25 blank lines are ignored.
27 The file consists of sections and variables. A section begins with
28 the name of the section in square brackets and continues until the next
29 section begins. Section names are case-insensitive. Only alphanumeric
30 characters, `-` and `.` are allowed in section names. Each variable
31 must belong to some section, which means that there must be a section
32 header before the first setting of a variable.
34 Sections can be further divided into subsections. To begin a subsection
35 put its name in double quotes, separated by space from the section name,
36 in the section header, like in the example below:
39 [section "subsection"]
43 Subsection names are case sensitive and can contain any characters except
44 newline and the null byte. Doublequote `"` and backslash can be included
45 by escaping them as `\"` and `\\`, respectively. Backslashes preceding
46 other characters are dropped when reading; for example, `\t` is read as
47 `t` and `\0` is read as `0` Section headers cannot span multiple lines.
48 Variables may belong directly to a section or to a given subsection. You
49 can have `[section]` if you have `[section "subsection"]`, but you don't
52 There is also a deprecated `[section.subsection]` syntax. With this
53 syntax, the subsection name is converted to lower-case and is also
54 compared case sensitively. These subsection names follow the same
55 restrictions as section names.
57 All the other lines (and the remainder of the line after the section
58 header) are recognized as setting variables, in the form
59 'name = value' (or just 'name', which is a short-hand to say that
60 the variable is the boolean "true").
61 The variable names are case-insensitive, allow only alphanumeric characters
62 and `-`, and must start with an alphabetic character.
64 A line that defines a value can be continued to the next line by
65 ending it with a `\`; the backquote and the end-of-line are
66 stripped. Leading whitespaces after 'name =', the remainder of the
67 line after the first comment character '#' or ';', and trailing
68 whitespaces of the line are discarded unless they are enclosed in
69 double quotes. Internal whitespaces within the value are retained
72 Inside double quotes, double quote `"` and backslash `\` characters
73 must be escaped: use `\"` for `"` and `\\` for `\`.
75 The following escape sequences (beside `\"` and `\\`) are recognized:
76 `\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
77 and `\b` for backspace (BS). Other char escape sequences (including octal
78 escape sequences) are invalid.
84 The `include` and `includeIf` sections allow you to include config
85 directives from another source. These sections behave identically to
86 each other with the exception that `includeIf` sections may be ignored
87 if their condition does not evaluate to true; see "Conditional includes"
90 You can include a config file from another by setting the special
91 `include.path` (or `includeIf.*.path`) variable to the name of the file
92 to be included. The variable takes a pathname as its value, and is
93 subject to tilde expansion. These variables can be given multiple times.
95 The contents of the included file are inserted immediately, as if they
96 had been found at the location of the include directive. If the value of the
97 variable is a relative path, the path is considered to
98 be relative to the configuration file in which the include directive
99 was found. See below for examples.
104 You can include a config file from another conditionally by setting a
105 `includeIf.<condition>.path` variable to the name of the file to be
108 The condition starts with a keyword followed by a colon and some data
109 whose format and meaning depends on the keyword. Supported keywords
114 The data that follows the keyword `gitdir:` is used as a glob
115 pattern. If the location of the .git directory matches the
116 pattern, the include condition is met.
118 The .git location may be auto-discovered, or come from `$GIT_DIR`
119 environment variable. If the repository is auto discovered via a .git
120 file (e.g. from submodules, or a linked worktree), the .git location
121 would be the final location where the .git directory is, not where the
124 The pattern can contain standard globbing wildcards and two additional
125 ones, `**/` and `/**`, that can match multiple path components. Please
126 refer to linkgit:gitignore[5] for details. For convenience:
128 * If the pattern starts with `~/`, `~` will be substituted with the
129 content of the environment variable `HOME`.
131 * If the pattern starts with `./`, it is replaced with the directory
132 containing the current config file.
134 * If the pattern does not start with either `~/`, `./` or `/`, `**/`
135 will be automatically prepended. For example, the pattern `foo/bar`
136 becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
138 * If the pattern ends with `/`, `**` will be automatically added. For
139 example, the pattern `foo/` becomes `foo/**`. In other words, it
140 matches "foo" and everything inside, recursively.
143 This is the same as `gitdir` except that matching is done
144 case-insensitively (e.g. on case-insensitive file sytems)
146 A few more notes on matching via `gitdir` and `gitdir/i`:
148 * Symlinks in `$GIT_DIR` are not resolved before matching.
150 * Both the symlink & realpath versions of paths will be matched
151 outside of `$GIT_DIR`. E.g. if ~/git is a symlink to
152 /mnt/storage/git, both `gitdir:~/git` and `gitdir:/mnt/storage/git`
155 This was not the case in the initial release of this feature in
156 v2.13.0, which only matched the realpath version. Configuration that
157 wants to be compatible with the initial release of this feature needs
158 to either specify only the realpath version, or both versions.
160 * Note that "../" is not special and will match literally, which is
161 unlikely what you want.
168 ; Don't trust file modes
173 external = /usr/local/bin/diff-wrapper
178 merge = refs/heads/devel
182 gitProxy="ssh" for "kernel.org"
183 gitProxy=default-proxy ; for the rest
186 path = /path/to/foo.inc ; include by absolute path
187 path = foo.inc ; find "foo.inc" relative to the current file
188 path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory
190 ; include if $GIT_DIR is /path/to/foo/.git
191 [includeIf "gitdir:/path/to/foo/.git"]
192 path = /path/to/foo.inc
194 ; include for all repositories inside /path/to/group
195 [includeIf "gitdir:/path/to/group/"]
196 path = /path/to/foo.inc
198 ; include for all repositories inside $HOME/to/group
199 [includeIf "gitdir:~/to/group/"]
200 path = /path/to/foo.inc
202 ; relative paths are always relative to the including
203 ; file (if the condition is true); their location is not
204 ; affected by the condition
205 [includeIf "gitdir:/path/to/group/"]
211 Values of many variables are treated as a simple string, but there
212 are variables that take values of specific types and there are rules
213 as to how to spell them.
217 When a variable is said to take a boolean value, many
218 synonyms are accepted for 'true' and 'false'; these are all
221 true;; Boolean true literals are `yes`, `on`, `true`,
222 and `1`. Also, a variable defined without `= <value>`
225 false;; Boolean false literals are `no`, `off`, `false`,
226 `0` and the empty string.
228 When converting a value to its canonical form using the `--type=bool` type
229 specifier, 'git config' will ensure that the output is "true" or
230 "false" (spelled in lowercase).
233 The value for many variables that specify various sizes can
234 be suffixed with `k`, `M`,... to mean "scale the number by
235 1024", "by 1024x1024", etc.
238 The value for a variable that takes a color is a list of
239 colors (at most two, one for foreground and one for background)
240 and attributes (as many as you want), separated by spaces.
242 The basic colors accepted are `normal`, `black`, `red`, `green`, `yellow`,
243 `blue`, `magenta`, `cyan` and `white`. The first color given is the
244 foreground; the second is the background.
246 Colors may also be given as numbers between 0 and 255; these use ANSI
247 256-color mode (but note that not all terminals may support this). If
248 your terminal supports it, you may also specify 24-bit RGB values as
251 The accepted attributes are `bold`, `dim`, `ul`, `blink`, `reverse`,
252 `italic`, and `strike` (for crossed-out or "strikethrough" letters).
253 The position of any attributes with respect to the colors
254 (before, after, or in between), doesn't matter. Specific attributes may
255 be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
258 An empty color string produces no color effect at all. This can be used
259 to avoid coloring specific elements without disabling color entirely.
261 For git's pre-defined color slots, the attributes are meant to be reset
262 at the beginning of each item in the colored output. So setting
263 `color.decorate.branch` to `black` will paint that branch name in a
264 plain `black`, even if the previous thing on the same output line (e.g.
265 opening parenthesis before the list of branch names in `log --decorate`
266 output) is set to be painted with `bold` or some other attribute.
267 However, custom log formats may do more complicated and layered
268 coloring, and the negated forms may be useful there.
271 A variable that takes a pathname value can be given a
272 string that begins with "`~/`" or "`~user/`", and the usual
273 tilde expansion happens to such a string: `~/`
274 is expanded to the value of `$HOME`, and `~user/` to the
275 specified user's home directory.
281 Note that this list is non-comprehensive and not necessarily complete.
282 For command-specific variables, you will find a more detailed description
283 in the appropriate manual page.
285 Other git-related tools may and do use their own variables. When
286 inventing new variables for use in your own tool, make sure their
287 names do not conflict with those that are used by Git itself and
288 other popular tools, and describe them in your documentation.
290 include::config/advice.txt[]
292 include::config/core.txt[]
294 include::config/add.txt[]
296 include::config/alias.txt[]
298 include::config/am.txt[]
300 include::config/apply.txt[]
302 include::config/blame.txt[]
304 include::config/branch.txt[]
306 include::config/browser.txt[]
308 include::config/checkout.txt[]
310 include::config/clean.txt[]
312 include::config/color.txt[]
314 include::config/column.txt[]
316 include::config/commit.txt[]
318 include::config/credential.txt[]
320 include::config/completion.txt[]
322 include::config/diff.txt[]
324 include::config/difftool.txt[]
326 include::config/fastimport.txt[]
328 include::config/fetch.txt[]
330 include::config/format.txt[]
332 include::config/filter.txt[]
334 include::config/fsck.txt[]
336 include::config/gc.txt[]
338 include::config/gitcvs.txt[]
340 include::config/gitweb.txt[]
342 include::config/grep.txt[]
344 include::config/gpg.txt[]
346 include::config/gui.txt[]
348 include::config/guitool.txt[]
350 include::config/help.txt[]
352 include::config/http.txt[]
354 include::config/i18n.txt[]
356 include::config/imap.txt[]
358 include::config/index.txt[]
360 include::config/init.txt[]
362 include::config/instaweb.txt[]
364 include::config/interactive.txt[]
366 include::config/log.txt[]
368 include::config/mailinfo.txt[]
370 include::config/mailmap.txt[]
372 include::config/man.txt[]
374 include::config/merge.txt[]
376 include::config/mergetool.txt[]
378 include::config/notes.txt[]
380 include::config/pack.txt[]
382 include::config/pager.txt[]
384 include::config/pretty.txt[]
386 include::config/protocol.txt[]
388 include::config/pull.txt[]
390 include::config/push.txt[]
392 include::config/rebase.txt[]
394 include::config/receive.txt[]
396 include::config/remote.txt[]
398 include::config/remotes.txt[]
400 include::config/repack.txt[]
402 include::config/rerere.txt[]
404 include::config/reset.txt[]
406 include::config/sendemail.txt[]
408 include::config/sequencer.txt[]
410 include::config/showbranch.txt[]
412 splitIndex.maxPercentChange::
413 When the split index feature is used, this specifies the
414 percent of entries the split index can contain compared to the
415 total number of entries in both the split index and the shared
416 index before a new shared index is written.
417 The value should be between 0 and 100. If the value is 0 then
418 a new shared index is always written, if it is 100 a new
419 shared index is never written.
420 By default the value is 20, so a new shared index is written
421 if the number of entries in the split index would be greater
422 than 20 percent of the total number of entries.
423 See linkgit:git-update-index[1].
425 splitIndex.sharedIndexExpire::
426 When the split index feature is used, shared index files that
427 were not modified since the time this variable specifies will
428 be removed when a new shared index file is created. The value
429 "now" expires all entries immediately, and "never" suppresses
430 expiration altogether.
431 The default value is "2.weeks.ago".
432 Note that a shared index file is considered modified (for the
433 purpose of expiration) each time a new split-index file is
434 either created based on it or read from it.
435 See linkgit:git-update-index[1].
437 include::config/ssh.txt[]
439 status.relativePaths::
440 By default, linkgit:git-status[1] shows paths relative to the
441 current directory. Setting this variable to `false` shows paths
442 relative to the repository root (this was the default for Git
446 Set to true to enable --short by default in linkgit:git-status[1].
447 The option --no-short takes precedence over this variable.
450 Set to true to enable --branch by default in linkgit:git-status[1].
451 The option --no-branch takes precedence over this variable.
453 status.displayCommentPrefix::
454 If set to true, linkgit:git-status[1] will insert a comment
455 prefix before each output line (starting with
456 `core.commentChar`, i.e. `#` by default). This was the
457 behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
461 The number of files to consider when performing rename detection
462 in linkgit:git-status[1] and linkgit:git-commit[1]. Defaults to
463 the value of diff.renameLimit.
466 Whether and how Git detects renames in linkgit:git-status[1] and
467 linkgit:git-commit[1] . If set to "false", rename detection is
468 disabled. If set to "true", basic rename detection is enabled.
469 If set to "copies" or "copy", Git will detect copies, as well.
470 Defaults to the value of diff.renames.
473 If set to true, linkgit:git-status[1] will display the number of
474 entries currently stashed away.
477 status.showUntrackedFiles::
478 By default, linkgit:git-status[1] and linkgit:git-commit[1] show
479 files which are not currently tracked by Git. Directories which
480 contain only untracked files, are shown with the directory name
481 only. Showing untracked files means that Git needs to lstat() all
482 the files in the whole repository, which might be slow on some
483 systems. So, this variable controls how the commands displays
484 the untracked files. Possible values are:
487 * `no` - Show no untracked files.
488 * `normal` - Show untracked files and directories.
489 * `all` - Show also individual files in untracked directories.
492 If this variable is not specified, it defaults to 'normal'.
493 This variable can be overridden with the -u|--untracked-files option
494 of linkgit:git-status[1] and linkgit:git-commit[1].
496 status.submoduleSummary::
498 If this is set to a non zero number or true (identical to -1 or an
499 unlimited number), the submodule summary will be enabled and a
500 summary of commits for modified submodules will be shown (see
501 --summary-limit option of linkgit:git-submodule[1]). Please note
502 that the summary output command will be suppressed for all
503 submodules when `diff.ignoreSubmodules` is set to 'all' or only
504 for those submodules where `submodule.<name>.ignore=all`. The only
505 exception to that rule is that status and commit will show staged
506 submodule changes. To
507 also view the summary for ignored submodules you can either use
508 the --ignore-submodules=dirty command-line option or the 'git
509 submodule summary' command, which shows a similar output but does
510 not honor these settings.
513 If this is set to true, the `git stash show` command without an
514 option will show the stash entry in patch form. Defaults to false.
515 See description of 'show' command in linkgit:git-stash[1].
518 If this is set to true, the `git stash show` command without an
519 option will show diffstat of the stash entry. Defaults to true.
520 See description of 'show' command in linkgit:git-stash[1].
522 include::submodule-config.txt[]
524 tag.forceSignAnnotated::
525 A boolean to specify whether annotated tags created should be GPG signed.
526 If `--annotate` is specified on the command line, it takes
527 precedence over this option.
530 This variable controls the sort ordering of tags when displayed by
531 linkgit:git-tag[1]. Without the "--sort=<value>" option provided, the
532 value of this variable will be used as the default.
535 This variable can be used to restrict the permission bits of
536 tar archive entries. The default is 0002, which turns off the
537 world write bit. The special value "user" indicates that the
538 archiving user's umask will be used instead. See umask(2) and
539 linkgit:git-archive[1].
541 transfer.fsckObjects::
542 When `fetch.fsckObjects` or `receive.fsckObjects` are
543 not set, the value of this variable is used instead.
546 When set, the fetch or receive will abort in the case of a malformed
547 object or a link to a nonexistent object. In addition, various other
548 issues are checked for, including legacy issues (see `fsck.<msg-id>`),
549 and potential security issues like the existence of a `.GIT` directory
550 or a malicious `.gitmodules` file (see the release notes for v2.2.1
551 and v2.17.1 for details). Other sanity and security checks may be
552 added in future releases.
554 On the receiving side, failing fsckObjects will make those objects
555 unreachable, see "QUARANTINE ENVIRONMENT" in
556 linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
557 instead be left unreferenced in the repository.
559 Due to the non-quarantine nature of the `fetch.fsckObjects`
560 implementation it can not be relied upon to leave the object store
561 clean like `receive.fsckObjects` can.
563 As objects are unpacked they're written to the object store, so there
564 can be cases where malicious objects get introduced even though the
565 "fetch" failed, only to have a subsequent "fetch" succeed because only
566 new incoming objects are checked, not those that have already been
567 written to the object store. That difference in behavior should not be
568 relied upon. In the future, such objects may be quarantined for
571 For now, the paranoid need to find some way to emulate the quarantine
572 environment if they'd like the same protection as "push". E.g. in the
573 case of an internal mirror do the mirroring in two steps, one to fetch
574 the untrusted objects, and then do a second "push" (which will use the
575 quarantine) to another internal repo, and have internal clients
576 consume this pushed-to repository, or embargo internal fetches and
577 only allow them once a full "fsck" has run (and no new fetches have
578 happened in the meantime).
581 String(s) `receive-pack` and `upload-pack` use to decide which
582 refs to omit from their initial advertisements. Use more than
583 one definition to specify multiple prefix strings. A ref that is
584 under the hierarchies listed in the value of this variable is
585 excluded, and is hidden when responding to `git push` or `git
586 fetch`. See `receive.hideRefs` and `uploadpack.hideRefs` for
587 program-specific versions of this config.
589 You may also include a `!` in front of the ref name to negate the entry,
590 explicitly exposing it, even if an earlier entry marked it as hidden.
591 If you have multiple hideRefs values, later entries override earlier ones
592 (and entries in more-specific config files override less-specific ones).
594 If a namespace is in use, the namespace prefix is stripped from each
595 reference before it is matched against `transfer.hiderefs` patterns.
596 For example, if `refs/heads/master` is specified in `transfer.hideRefs` and
597 the current namespace is `foo`, then `refs/namespaces/foo/refs/heads/master`
598 is omitted from the advertisements but `refs/heads/master` and
599 `refs/namespaces/bar/refs/heads/master` are still advertised as so-called
600 "have" lines. In order to match refs before stripping, add a `^` in front of
601 the ref name. If you combine `!` and `^`, `!` must be specified first.
603 Even if you hide refs, a client may still be able to steal the target
604 objects via the techniques described in the "SECURITY" section of the
605 linkgit:gitnamespaces[7] man page; it's best to keep private data in a
608 transfer.unpackLimit::
609 When `fetch.unpackLimit` or `receive.unpackLimit` are
610 not set, the value of this variable is used instead.
611 The default value is 100.
613 uploadarchive.allowUnreachable::
614 If true, allow clients to use `git archive --remote` to request
615 any tree, whether reachable from the ref tips or not. See the
616 discussion in the "SECURITY" section of
617 linkgit:git-upload-archive[1] for more details. Defaults to
620 uploadpack.hideRefs::
621 This variable is the same as `transfer.hideRefs`, but applies
622 only to `upload-pack` (and so affects only fetches, not pushes).
623 An attempt to fetch a hidden ref by `git fetch` will fail. See
624 also `uploadpack.allowTipSHA1InWant`.
626 uploadpack.allowTipSHA1InWant::
627 When `uploadpack.hideRefs` is in effect, allow `upload-pack`
628 to accept a fetch request that asks for an object at the tip
629 of a hidden ref (by default, such a request is rejected).
630 See also `uploadpack.hideRefs`. Even if this is false, a client
631 may be able to steal objects via the techniques described in the
632 "SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
633 best to keep private data in a separate repository.
635 uploadpack.allowReachableSHA1InWant::
636 Allow `upload-pack` to accept a fetch request that asks for an
637 object that is reachable from any ref tip. However, note that
638 calculating object reachability is computationally expensive.
639 Defaults to `false`. Even if this is false, a client may be able
640 to steal objects via the techniques described in the "SECURITY"
641 section of the linkgit:gitnamespaces[7] man page; it's best to
642 keep private data in a separate repository.
644 uploadpack.allowAnySHA1InWant::
645 Allow `upload-pack` to accept a fetch request that asks for any
649 uploadpack.keepAlive::
650 When `upload-pack` has started `pack-objects`, there may be a
651 quiet period while `pack-objects` prepares the pack. Normally
652 it would output progress information, but if `--quiet` was used
653 for the fetch, `pack-objects` will output nothing at all until
654 the pack data begins. Some clients and networks may consider
655 the server to be hung and give up. Setting this option instructs
656 `upload-pack` to send an empty keepalive packet every
657 `uploadpack.keepAlive` seconds. Setting this option to 0
658 disables keepalive packets entirely. The default is 5 seconds.
660 uploadpack.packObjectsHook::
661 If this option is set, when `upload-pack` would run
662 `git pack-objects` to create a packfile for a client, it will
663 run this shell command instead. The `pack-objects` command and
664 arguments it _would_ have run (including the `git pack-objects`
665 at the beginning) are appended to the shell command. The stdin
666 and stdout of the hook are treated as if `pack-objects` itself
667 was run. I.e., `upload-pack` will feed input intended for
668 `pack-objects` to the hook, and expects a completed packfile on
671 Note that this configuration variable is ignored if it is seen in the
672 repository-level config (this is a safety measure against fetching from
673 untrusted repositories).
675 uploadpack.allowFilter::
676 If this option is set, `upload-pack` will support partial
677 clone and partial fetch object filtering.
679 uploadpack.allowRefInWant::
680 If this option is set, `upload-pack` will support the `ref-in-want`
681 feature of the protocol version 2 `fetch` command. This feature
682 is intended for the benefit of load-balanced servers which may
683 not have the same view of what OIDs their refs point to due to
686 url.<base>.insteadOf::
687 Any URL that starts with this value will be rewritten to
688 start, instead, with <base>. In cases where some site serves a
689 large number of repositories, and serves them with multiple
690 access methods, and some users need to use different access
691 methods, this feature allows people to specify any of the
692 equivalent URLs and have Git automatically rewrite the URL to
693 the best alternative for the particular user, even for a
694 never-before-seen repository on the site. When more than one
695 insteadOf strings match a given URL, the longest match is used.
697 Note that any protocol restrictions will be applied to the rewritten
698 URL. If the rewrite changes the URL to use a custom protocol or remote
699 helper, you may need to adjust the `protocol.*.allow` config to permit
700 the request. In particular, protocols you expect to use for submodules
701 must be set to `always` rather than the default of `user`. See the
702 description of `protocol.allow` above.
704 url.<base>.pushInsteadOf::
705 Any URL that starts with this value will not be pushed to;
706 instead, it will be rewritten to start with <base>, and the
707 resulting URL will be pushed to. In cases where some site serves
708 a large number of repositories, and serves them with multiple
709 access methods, some of which do not allow push, this feature
710 allows people to specify a pull-only URL and have Git
711 automatically use an appropriate URL to push, even for a
712 never-before-seen repository on the site. When more than one
713 pushInsteadOf strings match a given URL, the longest match is
714 used. If a remote has an explicit pushurl, Git will ignore this
715 setting for that remote.
718 Your email address to be recorded in any newly created commits.
719 Can be overridden by the `GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_EMAIL`, and
720 `EMAIL` environment variables. See linkgit:git-commit-tree[1].
723 Your full name to be recorded in any newly created commits.
724 Can be overridden by the `GIT_AUTHOR_NAME` and `GIT_COMMITTER_NAME`
725 environment variables. See linkgit:git-commit-tree[1].
728 Instruct Git to avoid trying to guess defaults for `user.email`
729 and `user.name`, and instead retrieve the values only from the
730 configuration. For example, if you have multiple email addresses
731 and would like to use a different one for each repository, then
732 with this configuration option set to `true` in the global config
733 along with a name, Git will prompt you to set up an email before
734 making new commits in a newly cloned repository.
738 If linkgit:git-tag[1] or linkgit:git-commit[1] is not selecting the
739 key you want it to automatically when creating a signed tag or
740 commit, you can override the default selection with this variable.
741 This option is passed unchanged to gpg's --local-user parameter,
742 so you may specify a key using any method that gpg supports.
744 versionsort.prereleaseSuffix (deprecated)::
745 Deprecated alias for `versionsort.suffix`. Ignored if
746 `versionsort.suffix` is set.
749 Even when version sort is used in linkgit:git-tag[1], tagnames
750 with the same base version but different suffixes are still sorted
751 lexicographically, resulting e.g. in prerelease tags appearing
752 after the main release (e.g. "1.0-rc1" after "1.0"). This
753 variable can be specified to determine the sorting order of tags
754 with different suffixes.
756 By specifying a single suffix in this variable, any tagname containing
757 that suffix will appear before the corresponding main release. E.g. if
758 the variable is set to "-rc", then all "1.0-rcX" tags will appear before
759 "1.0". If specified multiple times, once per suffix, then the order of
760 suffixes in the configuration will determine the sorting order of tagnames
761 with those suffixes. E.g. if "-pre" appears before "-rc" in the
762 configuration, then all "1.0-preX" tags will be listed before any
763 "1.0-rcX" tags. The placement of the main release tag relative to tags
764 with various suffixes can be determined by specifying the empty suffix
765 among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and
766 "-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
767 are listed first, followed by "v4.8", then "v4.8-ckX" and finally
770 If more than one suffixes match the same tagname, then that tagname will
771 be sorted according to the suffix which starts at the earliest position in
772 the tagname. If more than one different matching suffixes start at
773 that earliest position, then that tagname will be sorted according to the
774 longest of those suffixes.
775 The sorting order between different suffixes is undefined if they are
776 in multiple config files.
779 Specify a web browser that may be used by some commands.
780 Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
783 worktree.guessRemote::
784 With `add`, if no branch argument, and neither of `-b` nor
785 `-B` nor `--detach` are given, the command defaults to
786 creating a new branch from HEAD. If `worktree.guessRemote` is
787 set to true, `worktree add` tries to find a remote-tracking
788 branch whose name uniquely matches the new branch name. If
789 such a branch exists, it is checked out and set as "upstream"
790 for the new branch. If no such match can be found, it falls
791 back to creating a new branch from the current HEAD.