summaryrefslogtreecommitdiff
path: root/Documentation/config.txt
AgeCommit message (Collapse)AuthorFilesLines
2017-06-26Merge branch 'dt/raise-core-packed-git-limit'Libravatar Junio C Hamano1-1/+2
Doc update for a topic already in 'master'. * dt/raise-core-packed-git-limit: docs: update 64-bit core.packedGitLimit default
2017-06-26Merge branch 'lb/status-stash-count'Libravatar Junio C Hamano1-3/+8
"git status" learned to optionally give how many stash entries the user has in its output. * lb/status-stash-count: glossary: define 'stash entry' status: add optional stash count information stash: update documentation to use 'stash entry'
2017-06-24Merge branch 'jk/warn-add-gitlink'Libravatar Junio C Hamano1-0/+3
Using "git add d/i/r" when d/i/r is the top of the working tree of a separate repository would create a gitlink in the index, which would appear as a not-quite-initialized submodule to others. We learned to give warnings when this happens. * jk/warn-add-gitlink: t: move "git add submodule" into test blocks add: warn when adding an embedded repository
2017-06-21docs: update 64-bit core.packedGitLimit defaultLibravatar Jeff King1-1/+2
We bumped the default in be4ca2905 (Increase core.packedGitLimit, 2017-04-20) but never adjusted the documentation to match. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18status: add optional stash count informationLibravatar Liam Beguin1-0/+5
Introduce '--show-stash' and its configuration option 'status.showStash' to allow git-status to show information about currently stashed entries. Signed-off-by: Liam Beguin <liambeguin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18stash: update documentation to use 'stash entry'Libravatar Liam Beguin1-3/+3
Most of the time, a 'stash entry' is called a 'stash'. Lets try to make this more consistent and use 'stash entry' instead. Signed-off-by: Liam Beguin <liambeguin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15add: warn when adding an embedded repositoryLibravatar Jeff King1-0/+3
It's an easy mistake to add a repository inside another repository, like: git clone $url git add . The resulting entry is a gitlink, but there's no matching .gitmodules entry. Trying to use "submodule init" (or clone with --recursive) doesn't do anything useful. Prior to v2.13, such an entry caused git-submodule to barf entirely. In v2.13, the entry is considered "inactive" and quietly ignored. Either way, no clone of your repository can do anything useful with the gitlink without the user manually adding the submodule config. In most cases, the user probably meant to either add a real submodule, or they forgot to put the embedded repository in their .gitignore file. Let's issue a warning when we see this case. There are a few things to note: - the warning will go in the git-add porcelain; anybody wanting to do low-level manipulation of the index is welcome to create whatever funny states they want. - we detect the case by looking for a newly added gitlink; updates via "git add submodule" are perfectly reasonable, and this avoids us having to investigate .gitmodules entirely - there's a command-line option to suppress the warning. This is needed for git-submodule itself (which adds the entry before adding any submodule config), but also provides a mechanism for other scripts doing submodule-like things. We could make this a hard error instead of a warning. However, we do add lots of sub-repos in our test suite. It's not _wrong_ to do so. It just creates a state where users may be surprised. Pointing them in the right direction with a gentle hint is probably the best option. There is a config knob that can disable the (long) hint. But I intentionally omitted a config knob to disable the warning entirely. Whether the warning is sensible or not is generally about context, not about the user's preferences. If there's a tool or workflow that adds gitlinks without matching .gitmodules, it should probably be taught about the new command-line option, rather than blanket-disabling the warning. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-13Merge branch 'sb/submodule-blanket-recursive'Libravatar Junio C Hamano1-0/+5
Many commands learned to pay attention to submodule.recurse configuration. * sb/submodule-blanket-recursive: builtin/fetch.c: respect 'submodule.recurse' option builtin/push.c: respect 'submodule.recurse' option builtin/grep.c: respect 'submodule.recurse' option Introduce 'submodule.recurse' option for worktree manipulators submodule loading: separate code path for .gitmodules and config overlay reset/checkout/read-tree: unify config callback for submodule recursion submodule test invocation: only pass additional arguments submodule recursing: do not write a config variable twice
2017-06-04Merge branch 'jk/url-insteadof-config'Libravatar Junio C Hamano1-0/+7
The interaction of "url.*.insteadOf" and custom URL scheme's whitelisting is now documented better. * jk/url-insteadof-config: docs/config: mention protocol implications of url.insteadOf
2017-06-04Merge branch 'ah/doc-rev-parse-short-default'Libravatar Junio C Hamano1-0/+1
Doc update. * ah/doc-rev-parse-short-default: doc: rewrite description for rev-parse --short
2017-06-01doc: rewrite description for rev-parse --shortLibravatar Andreas Heiduk1-0/+1
`git rev-parse --short` is not a generic modifier but just a variant of `--verify` and considers the given length only as a suggestion to ensure uniqueness. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-01Introduce 'submodule.recurse' option for worktree manipulatorsLibravatar Stefan Beller1-0/+5
Any command that understands '--recurse-submodules' can have its default changed to true, by setting the new 'submodule.recurse' option. This patch includes read-tree/checkout/reset for working tree manipulating commands. Later patches will cover other commands. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-01docs/config: mention protocol implications of url.insteadOfLibravatar Jeff King1-0/+7
If a URL rewrite switches the protocol to something nonstandard (like "persistent-https" for "https"), the user may be bitten by the fact that the default protocol restrictions are different between the two. Let's drop a note in insteadOf that points the user in the right direction. It would be nice if we could make this work out of the box, but we can't without knowing the security implications of the user's rewrite. Only the documentation for a particular remote helper can advise one way or the other. Since we do include the persistent-https helper in contrib/ (and since it was the helper in the real-world case that inspired that patch), let's also drop a note there. Suggested-by: Elliott Cable <me@ell.io> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-30Merge branch 'ab/conditional-config-with-symlinks'Libravatar Junio C Hamano1-0/+10
The recently introduced "[includeIf "gitdir:$dir"] path=..." mechansim has further been taught to take symlinks into account. The directory "$dir" specified in "gitdir:$dir" may be a symlink to a real location, not something that $(getcwd) may return. In such a case, a realpath of "$dir" is compared with the real path of the current repository to determine if the contents from the named path should be included. * ab/conditional-config-with-symlinks: config: match both symlink & realpath versions in IncludeIf.gitdir:*
2017-05-29Merge branch 'km/log-showsignature-doc'Libravatar Junio C Hamano1-0/+4
* km/log-showsignature-doc: config.txt: add an entry for log.showSignature
2017-05-29Merge branch 'jk/doc-config-include'Libravatar Junio C Hamano1-10/+21
Clarify documentation for include.path and includeIf.<condition>.path configuration variables. * jk/doc-config-include: docs/config: consistify include.path examples docs/config: avoid the term "expand" for includes docs/config: give a relative includeIf example docs/config: clarify include/includeIf relationship
2017-05-29Merge branch 'sg/core-filemode-doc-typofix'Libravatar Junio C Hamano1-1/+1
* sg/core-filemode-doc-typofix: docs/config.txt: fix indefinite article in core.fileMode description
2017-05-26docs/config.txt: fix indefinite article in core.fileMode descriptionLibravatar SZEDER Gábor1-1/+1
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-23Merge branch 'jt/push-options-doc'Libravatar Junio C Hamano1-3/+2
The receive-pack program now makes sure that the push certificate records the same set of push options used for pushing. * jt/push-options-doc: receive-pack: verify push options in cert docs: correct receive.advertisePushOptions default
2017-05-20config.txt: add an entry for log.showSignatureLibravatar Kyle Meyer1-0/+4
The configuration variable log.showSignature is mentioned in git-log's manpage. Document it in git-config's manpage as well. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-17config: match both symlink & realpath versions in IncludeIf.gitdir:*Libravatar Ævar Arnfjörð Bjarmason1-0/+10
Change the conditional inclusion mechanism to support e.g. gitdir:~/git_tree/repo where ~/git_tree is a symlink to /mnt/stuff/repo. This worked in the initial version of this facility[1], but regressed later in the series while solving a related bug[2]. Now gitdir: will match against the symlinked path (e.g. gitdir:~/git_tree/repo) in addition to the current /mnt/stuff/repo path. Since this is already in a release version note in the documentation that this behavior changed, so users who expect their configuration to work on both v2.13.0 and some future version of git with this fix aren't utterly confused. 1. commit 3efd0bedc6 ("config: add conditional include", 2017-03-01) 2. commit 86f9515708 ("config: resolve symlinks in conditional include's patterns", 2017-04-05) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-12docs/config: consistify include.path examplesLibravatar Jeff King1-2/+2
Most of the include examples use "foo.inc", but some use "foo". Since the string of examples are meant to show variations and how they differ, it's a good idea to change only one thing at a time. The filename differences are not relevant to what we're trying to show. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-12docs/config: avoid the term "expand" for includesLibravatar Jeff King1-4/+4
Using the word "expand" to refer to including the contents of another config file isn't really accurate, since it's a verbatim insertion. And it can cause confusion with the expanding of the path itself via things like "~". Let's clarify when we are referring to the contents versus the filename, and use appropriate verbs in each case. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-12docs/config: give a relative includeIf exampleLibravatar Jeff King1-0/+6
The changes in the previous commit hopefully clarify that the evaluation of an include "path" variable is the same no matter if it's in a conditional section or not. But since this question came up on the list, let's add an example that makes it obvious. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-12docs/config: clarify include/includeIf relationshipLibravatar Jeff King1-6/+11
The "includeIf" directives behave exactly like include ones, except they only kick in when the conditional is true. That was mentioned in the "conditional" section, but let's make it more clear for the whole "includes" section, since people don't necessarily read the documentation top to bottom. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-09docs: correct receive.advertisePushOptions defaultLibravatar Jonathan Tan1-3/+2
In commit c714e45 ("receive-pack: implement advertising and receiving push options", 2016-07-14), receive-pack was taught to (among other things) advertise that it understood push options, depending on configuration. It was documented that it advertised such ability by default; however, it actually does not. (In that commit, notice that advertise_push_options defaults to 0, unlike advertise_atomic_push which defaults to 1.) Update the documentation to state that it does not advertise the ability by default. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-28status: add color config slots for branch info in "--short --branch"Libravatar Stephen Kent1-1/+4
Add color config slots to be used in the status short-format when displaying local and remote tracking branch information. [jc: rebased on top of Peff's fix to 'git status' and tweaked the test to check both local and remote-tracking branch output] Signed-off-by: Stephen Kent <smkent@smkent.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-30Merge branch 'bw/submodule-is-active'Libravatar Junio C Hamano1-2/+13
"what URL do we want to update this submodule?" and "are we interested in this submodule?" are split into two distinct concepts, and then the way used to express the latter got extended, paving a way to make it easier to manage a project with many submodules and make it possible to later extend use of multiple worktrees for a project with submodules. * bw/submodule-is-active: submodule add: respect submodule.active and submodule.<name>.active submodule--helper init: set submodule.<name>.active clone: teach --recurse-submodules to optionally take a pathspec submodule init: initialize active submodules submodule: decouple url and submodule interest submodule--helper clone: check for configured submodules using helper submodule sync: use submodule--helper is-active submodule sync: skip work for inactive submodules submodule status: use submodule--helper is-active submodule--helper: add is-active subcommand
2017-03-28Merge branch 'km/config-grammofix' into maintLibravatar Junio C Hamano1-3/+3
Doc update. * km/config-grammofix: doc/config: grammar fixes for core.{editor,commentChar}
2017-03-27Merge branch 'km/config-grammofix'Libravatar Junio C Hamano1-3/+3
Doc update. * km/config-grammofix: doc/config: grammar fixes for core.{editor,commentChar}
2017-03-24Merge branch 'ab/push-default-doc-fix' into maintLibravatar Junio C Hamano1-0/+2
Doc fix. * ab/push-default-doc-fix: push: mention "push.default=tracking" in the documentation
2017-03-23doc/config: grammar fixes for core.{editor,commentChar}Libravatar Kyle Meyer1-3/+3
Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-21Merge branch 'ab/push-default-doc-fix'Libravatar Junio C Hamano1-0/+2
Doc fix. * ab/push-default-doc-fix: push: mention "push.default=tracking" in the documentation
2017-03-21Merge branch 'nd/conditional-config-include'Libravatar Junio C Hamano1-7/+69
The configuration file learned a new "includeIf.<condition>.path" that includes the contents of the given path only when the condition holds. This allows you to say "include this work-related bit only in the repositories under my ~/work/ directory". * nd/conditional-config-include: config: add conditional include config.txt: reflow the second include.path paragraph config.txt: clarify multiple key values in include.path
2017-03-21Merge branch 'dt/gc-ignore-old-gc-logs' into maintLibravatar Junio C Hamano1-0/+6
A "gc.log" file left by a backgrounded "gc --auto" disables further automatic gc; it has been taught to run at least once a day (by default) by ignoring a stale "gc.log" file that is too old. * dt/gc-ignore-old-gc-logs: gc: ignore old gc.log files
2017-03-20push: mention "push.default=tracking" in the documentationLibravatar Ævar Arnfjörð Bjarmason1-0/+2
Change the documentation for push.tracking=* to re-include a mention of what "tracking" does. The "tracking" option was renamed to "upstream" back in 53c4031 ("push.default: Rename 'tracking' to 'upstream'", 2011-02-16), this section was then subsequently rewritten in 87a70e4 ("config doc: rewrite push.default section", 2013-06-19) to remove any mention of "tracking". Maybe we should just warn or die nowadays if this option is in the config, but I had some old config of mine use this option, I'd forgotten that it was a synonym, and nothing in git's documentation mentioned that. That's bad, either we shouldn't support it at all, or we should document what it does. This patch does the latter. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-18submodule: decouple url and submodule interestLibravatar Brandon Williams1-2/+13
Currently the submodule.<name>.url config option is used to determine if a given submodule is of interest to the user. This ends up being cumbersome in a world where we want to have different submodules checked out in different worktrees or a more generalized mechanism to select which submodules are of interest. In a future with worktree support for submodules, there will be multiple working trees, each of which may only need a subset of the submodules checked out. The URL (which is where the submodule repository can be obtained) should not differ between different working trees. It may also be convenient for users to more easily specify groups of submodules they are interested in as opposed to running "git submodule init <path>" on each submodule they want checked out in their working tree. To this end two config options are introduced, submodule.active and submodule.<name>.active. The submodule.active config holds a pathspec that specifies which submodules should exist in the working tree. The submodule.<name>.active config is a boolean flag used to indicate if that particular submodule should exist in the working tree. Its important to note that submodule.active functions differently than the other configuration options since it takes a pathspec. This allows users to adopt at least two new workflows: 1. Submodules can be grouped with a leading directory, such that a pathspec e.g. 'lib/' would cover all library-ish modules to allow those who are interested in library-ish modules to set "submodule.active = lib/" just once to say any and all modules in 'lib/' are interesting. 2. Once the pathspec-attribute feature is invented, users can label submodules with attributes to group them, so that a broad pathspec with attribute requirements, e.g. ':(attr:lib)', can be used to say any and all modules with the 'lib' attribute are interesting. Since the .gitattributes file, just like the .gitmodules file, is tracked by the superproject, when a submodule moves in the superproject tree, the project can adjust which path gets the attribute in .gitattributes, just like it can adjust which path has the submodule in .gitmodules. Neither of these two additional configuration options solve the problem of wanting different submodules checked out in different worktrees because multiple worktrees share .git/config. Only once per-worktree configurations become a reality can this be solved, but this is a necessary preparatory step for that future. Given these multiple ways to check if a submodule is of interest, the more fine-grained submodule.<name>.active option has the highest order of precedence followed by the pathspec check against submodule.active. To ensure backwards compatibility, if neither of these options are set, git falls back to checking the submodule.<name>.url option to determine if a submodule is interesting. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-17Merge branch 'cc/split-index-config'Libravatar Junio C Hamano1-0/+29
The experimental "split index" feature has gained a few configuration variables to make it easier to use. * cc/split-index-config: (22 commits) Documentation/git-update-index: explain splitIndex.* Documentation/config: add splitIndex.sharedIndexExpire read-cache: use freshen_shared_index() in read_index_from() read-cache: refactor read_index_from() t1700: test shared index file expiration read-cache: unlink old sharedindex files config: add git_config_get_expiry() from gc.c read-cache: touch shared index files when used sha1_file: make check_and_freshen_file() non static Documentation/config: add splitIndex.maxPercentChange t1700: add tests for splitIndex.maxPercentChange read-cache: regenerate shared index if necessary config: add git_config_get_max_percent_split_change() Documentation/git-update-index: talk about core.splitIndex config var Documentation/config: add information for core.splitIndex t1700: add tests for core.splitIndex update-index: warn in case of split-index incoherency read-cache: add and then use tweak_split_index() split-index: add {add,remove}_split_index() functions config: add git_config_get_split_index() ...
2017-03-11config: add conditional includeLibravatar Nguyễn Thái Ngọc Duy1-0/+63
Sometimes a set of repositories want to share configuration settings among themselves that are distinct from other such sets of repositories. A user may work on two projects, each of which have multiple repositories, and use one user.email for one project while using another for the other. Setting $GIT_DIR/.config works, but if the penalty of forgetting to update $GIT_DIR/.config is high (especially when you end up cloning often), it may not be the best way to go. Having the settings in ~/.gitconfig, which would work for just one set of repositories, would not well in such a situation. Having separate ${HOME}s may add more problems than it solves. Extend the include.path mechanism that lets a config file include another config file, so that the inclusion can be done only when some conditions hold. Then ~/.gitconfig can say "include config-project-A only when working on project-A" for each project A the user works on. In this patch, the only supported grouping is based on $GIT_DIR (in absolute path), so you would need to group repositories by directory, or something like that to take advantage of it. We already have include.path for unconditional includes. This patch goes with includeIf.<condition>.path to make it clearer that a condition is required. The new config has the same backward compatibility approach as include.path: older git versions that don't understand includeIf will simply ignore them. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-11config.txt: reflow the second include.path paragraphLibravatar Nguyễn Thái Ngọc Duy1-5/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-11config.txt: clarify multiple key values in include.pathLibravatar Nguyễn Thái Ngọc Duy1-2/+2
The phrasing in this paragraph may give an impression that you can only use it once. Rephrase it a bit. Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-06Documentation/git-update-index: explain splitIndex.*Libravatar Christian Couder1-1/+1
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-06Documentation/config: add splitIndex.sharedIndexExpireLibravatar Christian Couder1-0/+12
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02Documentation: improve description for core.quotePathLibravatar Andreas Heiduk1-10/+13
Linking the description for pathname quoting to the configuration variable "core.quotePath" removes inconstistent and incomplete sections while also giving two hints how to deal with it: Either with "-c core.quotePath=false" or with "-z". Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-01Documentation/config: add splitIndex.maxPercentChangeLibravatar Christian Couder1-0/+13
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-01Documentation/config: add information for core.splitIndexLibravatar Christian Couder1-0/+4
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27Merge branch 'dt/gc-ignore-old-gc-logs'Libravatar Junio C Hamano1-0/+6
A "gc.log" file left by a backgrounded "gc --auto" disables further automatic gc; it has been taught to run at least once a day (by default) by ignoring a stale "gc.log" file that is too old. * dt/gc-ignore-old-gc-logs: gc: ignore old gc.log files
2017-02-27Merge branch 'sf/putty-w-args'Libravatar Junio C Hamano1-0/+11
The command line options for ssh invocation needs to be tweaked for some implementations of SSH (e.g. PuTTY plink wants "-P <port>" while OpenSSH wants "-p <port>" to specify port to connect to), and the variant was guessed when GIT_SSH environment variable is used to specify it. The logic to guess now applies to the command specified by the newer GIT_SSH_COMMAND and also core.sshcommand configuration variable, and comes with an escape hatch for users to deal with misdetected cases. * sf/putty-w-args: connect.c: stop conflating ssh command names and overrides connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config git_connect(): factor out SSH variant handling connect: rename tortoiseplink and putty variables connect: handle putty/plink also in GIT_SSH_COMMAND
2017-02-27Merge branch 'ps/urlmatch-wildcard'Libravatar Junio C Hamano1-1/+4
The <url> part in "http.<url>.<variable>" configuration variable can now be spelled with '*' that serves as wildcard. E.g. "http.https://*.example.com.proxy" can be used to specify the proxy used for https://a.example.com, https://b.example.com, etc., i.e. any host in the example.com domain. * ps/urlmatch-wildcard: urlmatch: allow globbing for the URL host part urlmatch: include host in urlmatch ranking urlmatch: split host and port fields in `struct url_info` urlmatch: enable normalization of URLs with globs mailmap: add Patrick Steinhardt's work address
2017-02-16Merge branch 'dp/submodule-doc-markup-fix'Libravatar Junio C Hamano1-1/+1
Doc fix. * dp/submodule-doc-markup-fix: config.txt: fix formatting of submodule.alternateErrorStrategy section