From: Junio C Hamano Date: Wed, 10 Oct 2018 03:37:15 +0000 (+0900) Subject: Merge branch 'nd/config-split' X-Git-Tag: v2.20.0-rc0~200 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3ba371f9df8ae4439c524ed45529b6e7e51cfed5;p=thirdparty%2Fgit.git Merge branch 'nd/config-split' 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 --- 3ba371f9df8ae4439c524ed45529b6e7e51cfed5 diff --cc Documentation/config.txt index ad0f4510c3,a43a958a8a..fa52b19dff --- a/Documentation/config.txt +++ b/Documentation/config.txt @@@ -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..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=