Documentation/config/push.txt

   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
  22 * `nothing` - 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` - push the current branch to update a branch with the same
  27   name on the receiving end.  Works in both central and non-central
  28   workflows.
  29
  30 * `upstream` - push the current branch back to the branch whose
  31   changes are usually integrated into the current branch (which is
  32   called `@{upstream}`).  This mode only makes sense if you are
  33   pushing to the same repository you would normally pull from
  34   (i.e. central workflow).
  35
  36 * `tracking` - This is a deprecated synonym for `upstream`.
  37
  38 * `simple` - pushes the current branch with the same name on the remote.
  39 +
  40 If you are working on a centralized workflow (pushing to the same repository you
  41 pull from, which is typically `origin`), then you need to configure an upstream
  42 branch with the same name.
  43 +
  44 This mode is the default since Git 2.0, and is the safest option suited for
  45 beginners.
  46
  47 * `matching` - push all branches having the same name on both ends.
  48   This makes the repository you are pushing to remember the set of
  49   branches that will be pushed out (e.g. if you always push 'maint'
  50   and 'master' there and no other branches, the repository you push
  51   to will have these two branches, and your local 'maint' and
  52   'master' will be pushed there).
  53 +
  54 To use this mode effectively, you have to make sure _all_ the
  55 branches you would push out are ready to be pushed out before
  56 running 'git push', as the whole point of this mode is to allow you
  57 to push all of the branches in one go.  If you usually finish work
  58 on only one branch and push out the result, while other branches are
  59 unfinished, this mode is not for you.  Also this mode is not
  60 suitable for pushing into a shared central repository, as other
  61 people may add new branches there, or update the tip of existing
  62 branches outside your control.
  63 +
  64 This used to be the default, but not since Git 2.0 (`simple` is the
  65 new default).
  66
  67 --
  68
  69 push.followTags::
  70         If set to true enable `--follow-tags` option by default.  You
  71         may override this configuration at time of push by specifying
  72         `--no-follow-tags`.
  73
  74 push.gpgSign::
  75         May be set to a boolean value, or the string 'if-asked'. A true
  76         value causes all pushes to be GPG signed, as if `--signed` is
  77         passed to linkgit:git-push[1]. The string 'if-asked' causes
  78         pushes to be signed if the server supports it, as if
  79         `--signed=if-asked` is passed to 'git push'. A false value may
  80         override a value from a lower-priority config file. An explicit
  81         command-line flag always overrides this config option.
  82
  83 push.pushOption::
  84         When no `--push-option=<option>` argument is given from the
  85         command line, `git push` behaves as if each <value> of
  86         this variable is given as `--push-option=<value>`.
  87 +
  88 This is a multi-valued variable, and an empty value can be used in a
  89 higher priority configuration file (e.g. `.git/config` in a
  90 repository) to clear the values inherited from a lower priority
  91 configuration files (e.g. `$HOME/.gitconfig`).
  92 +
  93 ----
  94
  95 Example:
  96
  97 /etc/gitconfig
  98   push.pushoption = a
  99   push.pushoption = b
 100
 101 ~/.gitconfig
 102   push.pushoption = c
 103
 104 repo/.git/config
 105   push.pushoption =
 106   push.pushoption = b
 107
 108 This will result in only b (a and c are cleared).
 109
 110 ----
 111
 112 push.recurseSubmodules::
 113         Make sure all submodule commits used by the revisions to be pushed
 114         are available on a remote-tracking branch. If the value is 'check'
 115         then Git will verify that all submodule commits that changed in the
 116         revisions to be pushed are available on at least one remote of the
 117         submodule. If any commits are missing, the push will be aborted and
 118         exit with non-zero status. If the value is 'on-demand' then all
 119         submodules that changed in the revisions to be pushed will be
 120         pushed. If on-demand was not able to push all necessary revisions
 121         it will also be aborted and exit with non-zero status. If the value
 122         is 'no' then default behavior of ignoring submodules when pushing
 123         is retained. You may override this configuration at time of push by
 124         specifying '--recurse-submodules=check|on-demand|no'.
 125         If not set, 'no' is used by default, unless 'submodule.recurse' is
 126         set (in which case a 'true' value means 'on-demand').
 127
 128 push.useForceIfIncludes::
 129         If set to "true", it is equivalent to specifying
 130         `--force-if-includes` as an option to linkgit:git-push[1]
 131         in the command line. Adding `--no-force-if-includes` at the
 132         time of push overrides this configuration setting.
 133
 134 push.negotiate::
 135         If set to "true", attempt to reduce the size of the packfile
 136         sent by rounds of negotiation in which the client and the
 137         server attempt to find commits in common. If "false", Git will
 138         rely solely on the server's ref advertisement to find commits
 139         in common.
 140
 141 push.useBitmaps::
 142         If set to "false", disable use of bitmaps for "git push" even if
 143         `pack.useBitmaps` is "true", without preventing other git operations
 144         from using bitmaps. Default is true.