git.oblomov.eu Git - git/blob - Documentation/config/push.txt

   1 push.default::
   2         Defines the action `git push` should take if no refspec is
   3         given (whether from the command-line, config, or elsewhere).
   4         Different values are well-suited for
   5         specific workflows; for instance, in a purely central workflow
   6         (i.e. the fetch source is equal to the push destination),
   7         `upstream` is probably what you want.  Possible values are:
   8 +
   9 --
  10
  11 * `nothing` - do not push anything (error out) unless a refspec is
  12   given. This is primarily meant for people who want to
  13   avoid mistakes by always being explicit.
  14
  15 * `current` - push the current branch to update a branch with the same
  16   name on the receiving end.  Works in both central and non-central
  17   workflows.
  18
  19 * `upstream` - push the current branch back to the branch whose
  20   changes are usually integrated into the current branch (which is
  21   called `@{upstream}`).  This mode only makes sense if you are
  22   pushing to the same repository you would normally pull from
  23   (i.e. central workflow).
  24
  25 * `tracking` - This is a deprecated synonym for `upstream`.
  26
  27 * `simple` - pushes the current branch with the same name on the remote.
  28 +
  29 If you are working on a centralized workflow (pushing to the same repository you
  30 pull from, which is typically `origin`), then you need to configure an upstream
  31 branch with the same name.
  32 +
  33 This mode is the default since Git 2.0, and is the safest option suited for
  34 beginners.
  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 +
  43 To use this mode effectively, you have to make sure _all_ the
  44 branches you would push out are ready to be pushed out before
  45 running 'git push', as the whole point of this mode is to allow you
  46 to push all of the branches in one go.  If you usually finish work
  47 on only one branch and push out the result, while other branches are
  48 unfinished, this mode is not for you.  Also this mode is not
  49 suitable for pushing into a shared central repository, as other
  50 people may add new branches there, or update the tip of existing
  51 branches outside your control.
  52 +
  53 This used to be the default, but not since Git 2.0 (`simple` is the
  54 new default).
  55
  56 --
  57
  58 push.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
  63 push.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
  72 push.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 +
  77 This is a multi-valued variable, and an empty value can be used in a
  78 higher priority configuration file (e.g. `.git/config` in a
  79 repository) to clear the values inherited from a lower priority
  80 configuration files (e.g. `$HOME/.gitconfig`).
  81 +
  82 ----
  83
  84 Example:
  85
  86 /etc/gitconfig
  87   push.pushoption = a
  88   push.pushoption = b
  89
  90 ~/.gitconfig
  91   push.pushoption = c
  92
  93 repo/.git/config
  94   push.pushoption =
  95   push.pushoption = b
  96
  97 This will result in only b (a and c are cleared).
  98
  99 ----
 100
 101 push.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'.
 114         If not set, 'no' is used by default, unless 'submodule.recurse' is
 115         set (in which case a 'true' value means 'on-demand').
 116
 117 push.useForceIfIncludes::
 118         If set to "true", it is equivalent to specifying
 119         `--force-if-includes` as an option to linkgit:git-push[1]
 120         in the command line. Adding `--no-force-if-includes` at the
 121         time of push overrides this configuration setting.
 122
 123 push.negotiate::
 124         If set to "true", attempt to reduce the size of the packfile
 125         sent by rounds of negotiation in which the client and the
 126         server attempt to find commits in common. If "false", Git will
 127         rely solely on the server's ref advertisement to find commits
 128         in common.