1push.default:: 2 Defines the action `git push` should take if no refspec is 3 explicitly given. Different values are well-suited for 4 specific workflows; for instance, in a purely central workflow 5 (i.e. the fetch source is equal to the push destination), 6 `upstream` is probably what you want. Possible values are: 7+ 8-- 9 10* `nothing` - do not push anything (error out) unless a refspec is 11 explicitly given. This is primarily meant for people who want to 12 avoid mistakes by always being explicit. 13 14* `current` - push the current branch to update a branch with the same 15 name on the receiving end. Works in both central and non-central 16 workflows. 17 18* `upstream` - push the current branch back to the branch whose 19 changes are usually integrated into the current branch (which is 20 called `@{upstream}`). This mode only makes sense if you are 21 pushing to the same repository you would normally pull from 22 (i.e. central workflow). 23 24* `tracking` - This is a deprecated synonym for `upstream`. 25 26* `simple` - in centralized workflow, work like `upstream` with an 27 added safety to refuse to push if the upstream branch's name is 28 different from the local one. 29+ 30When pushing to a remote that is different from the remote you normally 31pull from, work as `current`. This is the safest option and is suited 32for beginners. 33+ 34This mode has become the default in Git 2.0. 35 36* `matching` - push all branches having the same name on both ends. 37 This makes the repository you are pushing to remember the set of 38 branches that will be pushed out (e.g. if you always push 'maint' 39 and 'master' there and no other branches, the repository you push 40 to will have these two branches, and your local 'maint' and 41 'master' will be pushed there). 42+ 43To use this mode effectively, you have to make sure _all_ the 44branches you would push out are ready to be pushed out before 45running 'git push', as the whole point of this mode is to allow you 46to push all of the branches in one go. If you usually finish work 47on only one branch and push out the result, while other branches are 48unfinished, this mode is not for you. Also this mode is not 49suitable for pushing into a shared central repository, as other 50people may add new branches there, or update the tip of existing 51branches outside your control. 52+ 53This used to be the default, but not since Git 2.0 (`simple` is the 54new default). 55 56-- 57 58push.followTags:: 59 If set to true enable `--follow-tags` option by default. You 60 may override this configuration at time of push by specifying 61 `--no-follow-tags`. 62 63push.gpgSign:: 64 May be set to a boolean value, or the string 'if-asked'. A true 65 value causes all pushes to be GPG signed, as if `--signed` is 66 passed to linkgit:git-push[1]. The string 'if-asked' causes 67 pushes to be signed if the server supports it, as if 68 `--signed=if-asked` is passed to 'git push'. A false value may 69 override a value from a lower-priority config file. An explicit 70 command-line flag always overrides this config option. 71 72push.pushOption:: 73 When no `--push-option=<option>` argument is given from the 74 command line, `git push` behaves as if each <value> of 75 this variable is given as `--push-option=<value>`. 76+ 77This is a multi-valued variable, and an empty value can be used in a 78higher priority configuration file (e.g. `.git/config` in a 79repository) to clear the values inherited from a lower priority 80configuration files (e.g. `$HOME/.gitconfig`). 81+ 82-- 83 84Example: 85 86/etc/gitconfig 87 push.pushoption = a 88 push.pushoption = b 89 90~/.gitconfig 91 push.pushoption = c 92 93repo/.git/config 94 push.pushoption = 95 push.pushoption = b 96 97This will result in only b (a and c are cleared). 98 99-- 100 101push.recurseSubmodules:: 102 Make sure all submodule commits used by the revisions to be pushed 103 are available on a remote-tracking branch. If the value is 'check' 104 then Git will verify that all submodule commits that changed in the 105 revisions to be pushed are available on at least one remote of the 106 submodule. If any commits are missing, the push will be aborted and 107 exit with non-zero status. If the value is 'on-demand' then all 108 submodules that changed in the revisions to be pushed will be 109 pushed. If on-demand was not able to push all necessary revisions 110 it will also be aborted and exit with non-zero status. If the value 111 is 'no' then default behavior of ignoring submodules when pushing 112 is retained. You may override this configuration at time of push by 113 specifying '--recurse-submodules=check|on-demand|no'.