| 1 | `push.autoSetupRemote`:: |
| 2 | If set to `true` assume `--set-upstream` on default push when no |
| 3 | upstream tracking exists for the current branch; this option |
| 4 | takes effect with `push.default` options `simple`, `upstream`, |
| 5 | and `current`. It is useful if by default you want new branches |
| 6 | to be pushed to the default remote (like the behavior of |
| 7 | `push.default=current`) and you also want the upstream tracking |
| 8 | to be set. Workflows most likely to benefit from this option are |
| 9 | `simple` central workflows where all branches are expected to |
| 10 | have the same name on the remote. |
| 11 | |
| 12 | `push.default`:: |
| 13 | Defines the action `git push` should take if no refspec is |
| 14 | given (whether from the command-line, config, or elsewhere). |
| 15 | Different values are well-suited for |
| 16 | specific workflows; for instance, in a purely central workflow |
| 17 | (i.e. the fetch source is equal to the push destination), |
| 18 | `upstream` is probably what you want. Possible values are: |
| 19 | + |
| 20 | -- |
| 21 | `nothing`;; |
| 22 | do not push anything (error out) unless a refspec is |
| 23 | given. This is primarily meant for people who want to |
| 24 | avoid mistakes by always being explicit. |
| 25 | |
| 26 | `current`;; |
| 27 | push the current branch to update a branch with the same |
| 28 | name on the receiving end. Works in both central and non-central |
| 29 | workflows. |
| 30 | |
| 31 | `upstream`;; |
| 32 | push the current branch back to the branch whose |
| 33 | changes are usually integrated into the current branch (which is |
| 34 | called `@{upstream}`). This mode only makes sense if you are |
| 35 | pushing to the same repository you would normally pull from |
| 36 | (i.e. central workflow). |
| 37 | |
| 38 | `tracking`;; |
| 39 | this is a deprecated synonym for `upstream`. |
| 40 | |
| 41 | `simple`;; |
| 42 | push the current branch with the same name on the remote. |
| 43 | + |
| 44 | This mode requires that the remote repository to be pushed to is |
| 45 | known. When pushing back to the same remote you pull from, the |
| 46 | current branch must also have an upstream tracking branch with the |
| 47 | same name. |
| 48 | + |
| 49 | This mode is the default since Git 2.0, and is the safest option suited for |
| 50 | beginners. |
| 51 | |
| 52 | `matching`;; |
| 53 | push all branches having the same name on both ends. |
| 54 | This makes the repository you are pushing to remember the set of |
| 55 | branches that will be pushed out (e.g. if you always push `maint` |
| 56 | and `master` there and no other branches, the repository you push |
| 57 | to will have these two branches, and your local `maint` and |
| 58 | `master` will be pushed there). |
| 59 | + |
| 60 | To use this mode effectively, you have to make sure _all_ the |
| 61 | branches you would push out are ready to be pushed out before |
| 62 | running `git push`, as the whole point of this mode is to allow you |
| 63 | to push all of the branches in one go. If you usually finish work |
| 64 | on only one branch and push out the result, while other branches are |
| 65 | unfinished, this mode is not for you. Also this mode is not |
| 66 | suitable for pushing into a shared central repository, as other |
| 67 | people may add new branches there, or update the tip of existing |
| 68 | branches outside your control. |
| 69 | + |
| 70 | This used to be the default, but not since Git 2.0 (`simple` is the |
| 71 | new default). |
| 72 | |
| 73 | -- |
| 74 | |
| 75 | `push.followTags`:: |
| 76 | If set to true, enable `--follow-tags` option by default. You |
| 77 | may override this configuration at time of push by specifying |
| 78 | `--no-follow-tags`. |
| 79 | |
| 80 | `push.gpgSign`:: |
| 81 | May be set to a boolean value, or the string `if-asked`. A true |
| 82 | value causes all pushes to be GPG signed, as if `--signed` is |
| 83 | passed to linkgit:git-push[1]. The string `if-asked` causes |
| 84 | pushes to be signed if the server supports it, as if |
| 85 | `--signed=if-asked` is passed to `git push`. A false value may |
| 86 | override a value from a lower-priority config file. An explicit |
| 87 | command-line flag always overrides this config option. |
| 88 | |
| 89 | `push.pushOption`:: |
| 90 | When no `--push-option=<option>` argument is given from the |
| 91 | command line, `git push` behaves as if each _<option>_ of |
| 92 | this variable is given as `--push-option=<option>`. |
| 93 | + |
| 94 | This is a multi-valued variable, and an empty value can be used in a |
| 95 | higher priority configuration file (e.g. `.git/config` in a |
| 96 | repository) to clear the values inherited from a lower priority |
| 97 | configuration files (e.g. `$HOME/.gitconfig`). |
| 98 | + |
| 99 | ---- |
| 100 | |
| 101 | Example: |
| 102 | |
| 103 | /etc/gitconfig |
| 104 | push.pushoption = a |
| 105 | push.pushoption = b |
| 106 | |
| 107 | ~/.gitconfig |
| 108 | push.pushoption = c |
| 109 | |
| 110 | repo/.git/config |
| 111 | push.pushoption = |
| 112 | push.pushoption = b |
| 113 | |
| 114 | This will result in only b (a and c are cleared). |
| 115 | |
| 116 | ---- |
| 117 | |
| 118 | `push.recurseSubmodules`:: |
| 119 | May be `check`, `on-demand`, `only`, or `no`, with the same behavior |
| 120 | as that of `push --recurse-submodules`. |
| 121 | If not set, `no` is used by default, unless `submodule.recurse` is |
| 122 | set (in which case a `true` value means `on-demand`). |
| 123 | |
| 124 | `push.useForceIfIncludes`:: |
| 125 | If set to `true`, it is equivalent to specifying |
| 126 | `--force-if-includes` as an option to linkgit:git-push[1] |
| 127 | in the command line. Adding `--no-force-if-includes` at the |
| 128 | time of push overrides this configuration setting. |
| 129 | |
| 130 | `push.negotiate`:: |
| 131 | If set to `true`, attempt to reduce the size of the packfile |
| 132 | sent by rounds of negotiation in which the client and the |
| 133 | server attempt to find commits in common. If `false`, Git will |
| 134 | rely solely on the server's ref advertisement to find commits |
| 135 | in common. |
| 136 | |
| 137 | `push.useBitmaps`:: |
| 138 | If set to `false`, disable use of bitmaps for `git push` even if |
| 139 | `pack.useBitmaps` is `true`, without preventing other git operations |
| 140 | from using bitmaps. Default is `true`. |