Merge branch 'nd/config-split'
authorJunio C Hamano <gitster@pobox.com>
Wed, 10 Oct 2018 03:37:15 +0000 (12:37 +0900)
committerJunio C Hamano <gitster@pobox.com>
Wed, 10 Oct 2018 03:37:15 +0000 (12:37 +0900)
Split Documentation/config.txt for easier maintenance.

* nd/config-split:
config.txt: move submodule part out to a separate file
config.txt: move sequence.editor out of "core" part
config.txt: move sendemail part out to a separate file
config.txt: move receive part out to a separate file
config.txt: move push part out to a separate file
config.txt: move pull part out to a separate file
config.txt: move gui part out to a separate file
config.txt: move gitcvs part out to a separate file
config.txt: move format part out to a separate file
config.txt: move fetch part out to a separate file
config.txt: follow camelCase naming

1  2 
Documentation/config.txt
index ad0f4510c39c977bc95b41776eda4088d7a89885,a43a958a8abadf7f5fd7cc9de166e9ab92cf1c96..fa52b19dffcc515b76dc988088dd4cc2bd7c94f8
@@@ -2856,160 -2550,11 +2578,13 @@@ protocol.version:
  * `1` - the original wire protocol with the addition of a version string
    in the initial response from the server.
  
 +* `2` - link:technical/protocol-v2.html[wire protocol version 2].
 +
  --
  
- 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.
- +
- When `merges`, pass the `--rebase-merges` option to 'git rebase'
- so that the local merge commits are included in the rebase (see
- linkgit:git-rebase[1] for details).
- +
- When preserve, also pass `--preserve-merges` along to 'git rebase'
- so that locally committed merge commits will not be flattened
- by running 'git pull'.
- +
- When the value is `interactive`, the rebase is run in interactive mode.
- +
- *NOTE*: this is a possibly dangerous operation; do *not* use
- it unless you understand the implications (see linkgit:git-rebase[1]
- for details).
- 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
-       explicitly given.  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
-   explicitly 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` - in centralized workflow, work like `upstream` with an
-   added safety to refuse to push if the upstream branch's name is
-   different from the local one.
- +
- When pushing to a remote that is different from the remote you normally
- pull from, work as `current`.  This is the safest option and is suited
- for beginners.
- +
- This mode has become the default in Git 2.0.
- * `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 linkgit: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`).
- +
- --
- Example:
- /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).
- --
+ include::pull-config.txt[]
  
- 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'.
+ include::push-config.txt[]
  
  include::rebase-config.txt[]