SYNOPSIS
--------
[verse]
-'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
+'git push' [--all | --mirror | --tags] [--follow-tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream]
- [<repository> [<refspec>...]]
+ [--no-verify] [<repository> [<refspec>...]]
DESCRIPTION
-----------
every time you push into it, by setting up 'hooks' there. See
documentation for linkgit:git-receive-pack[1].
+When the command line does not specify where to push with the
+`<repository>` argument, `branch.*.remote` configuration for the
+current branch is consulted to determine where to push. If the
+configuration is missing, it defaults to 'origin'.
+
+When the command line does not specify what to push with `<refspec>...`
+arguments or `--all`, `--mirror`, `--tags` options, the command finds
+the default `<refspec>` by consulting `remote.*.push` configuration,
+and if it is not found, honors `push.default` configuration to decide
+what to push (See gitlink:git-config[1] for the meaning of `push.default`).
+
OPTIONS[[OPTIONS]]
------------------
of a remote (see the section <<REMOTES,REMOTES>> below).
<refspec>...::
+ Specify what destination ref to update with what source object.
The format of a <refspec> parameter is an optional plus
- `+`, followed by the source ref <src>, followed
+ `+`, followed by the source object <src>, followed
by a colon `:`, followed by the destination ref <dst>.
- It is used to specify with what <src> object the <dst> ref
- in the remote repository is to be updated.
+
The <src> is often the name of the branch you would want to push, but
it can be any arbitrary "SHA-1 expression", such as `master~4` or
updated.
+
The object referenced by <src> is used to update the <dst> reference
-on the remote side, but by default this is only allowed if the
-update can fast-forward <dst>. By having the optional leading `+`,
-you can tell git to update the <dst> ref even when the update is not a
-fast-forward. This does *not* attempt to merge <src> into <dst>. See
+on the remote side. By default this is only allowed if <dst> is not
+a tag (annotated or lightweight), and then only if it can fast-forward
+<dst>. By having the optional leading `+`, you can tell Git to update
+the <dst> ref even if it is not allowed by default (e.g., it is not a
+fast-forward.) This does *not* attempt to merge <src> into <dst>. See
EXAMPLES below for details.
+
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
the remote repository.
+
The special refspec `:` (or `+:` to allow non-fast-forward updates)
-directs git to push "matching" branches: for every branch that exists on
+directs Git to push "matching" branches: for every branch that exists on
the local side, the remote side is updated if a branch of the same name
-already exists on the remote side. This is the default operation mode
-if no explicit refspec is found (that is neither on the command line
-nor in any Push line of the corresponding remotes file---see below).
+already exists on the remote side.
--all::
Instead of naming each ref to push, specifies that all
addition to refspecs explicitly listed on the command
line.
+--follow-tags::
+ Push all the refs that would be pushed without this option,
+ and also push annotated tags in `refs/tags` that are missing
+ from the remote but are pointing at committish that are
+ reachable from the refs being pushed.
+
--receive-pack=<git-receive-pack>::
--exec=<git-receive-pack>::
Path to the 'git-receive-pack' program on the remote
not an ancestor of the local ref used to overwrite it.
This flag disables the check. This can cause the
remote repository to lose commits; use it with care.
+ Note that `--force` applies to all the refs that are pushed,
+ hence using it with `push.default` set to `matching` or with
+ multiple push destinations configured with `remote.*.push`
+ may overwrite refs other than the current branch (including
+ local refs that are strictly behind their remote counterpart).
+ To force a push to only one branch, use a `+` in front of the
+ refspec to push (e.g `git push origin +master` to force a push
+ to the `master` branch). See the `<refspec>...` section above
+ for details.
--repo=<repository>::
This option is only relevant if no <repository> argument is
linkgit:git-pull[1] and other commands. For more information,
see 'branch.<name>.merge' in linkgit:git-config[1].
---thin::
---no-thin::
+--[no-]thin::
These options are passed to linkgit:git-send-pack[1]. A thin transfer
significantly reduces the amount of sent data when the sender and
receiver share many of the same objects in common. The default is
is specified. This flag forces progress status even if the
standard error stream is not directed to a terminal.
---recurse-submodules=check::
- Check whether all submodule commits used by the revisions to be
- pushed are available on a remote tracking branch. Otherwise the
- push will be aborted and the command will exit with non-zero status.
+--recurse-submodules=check|on-demand::
+ Make sure all submodule commits used by the revisions to be
+ pushed are available on a remote-tracking branch. If 'check' is
+ used Git will verify that all submodule commits that changed in
+ the revisions to be pushed are available on at least one remote
+ of the submodule. If any commits are missing the push will be
+ aborted and exit with non-zero status. If 'on-demand' is used
+ all submodules that changed in the revisions to be pushed will
+ be pushed. If on-demand was not able to push all necessary
+ revisions it will also be aborted and exit with non-zero status.
+
+--[no-]verify::
+ Toggle the pre-push hook (see linkgit:githooks[5]). The
+ default is \--verify, giving the hook a chance to prevent the
+ push. With \--no-verify, the hook is bypassed completely.
include::urls-remotes.txt[]
------
The output of "git push" depends on the transport method used; this
-section describes the output when pushing over the git protocol (either
+section describes the output when pushing over the Git protocol (either
locally or via ssh).
The status of the push is output in tabular form, with each line
----------------
Further suppose that the other person already pushed changes leading to A
-back to the original repository you two obtained the original commit X.
+back to the original repository from which you two obtained the original
+commit X.
The push done by the other person updated the branch that used to point at
commit X to point at commit A. It is a fast-forward.
`git push origin :`.
+
The default behavior of this command when no <refspec> is given can be
-configured by setting the `push` option of the remote.
+configured by setting the `push` option of the remote, or the `push.default`
+configuration variable.
+
For example, to default to pushing only the current branch to `origin`
use `git config remote.origin.push HEAD`. Any valid <refspec> (like
A handy way to push the current branch to the same name on the
remote.
-`git push origin master:satellite/master dev:satellite/dev`::
+`git push mothership master:satellite/master dev:satellite/dev`::
Use the source ref that matches `master` (e.g. `refs/heads/master`)
to update the ref that matches `satellite/master` (most probably
- `refs/remotes/satellite/master`) in the `origin` repository, then
+ `refs/remotes/satellite/master`) in the `mothership` repository;
do the same for `dev` and `satellite/dev`.
++
+This is to emulate `git fetch` run on the `mothership` using `git
+push` that is run in the opposite direction in order to integrate
+the work done on `satellite`, and is often necessary when you can
+only make connection in one way (i.e. satellite can ssh into
+mothership but mothership cannot initiate connection to satellite
+because the latter is behind a firewall or does not run sshd).
++
+After running this `git push` on the `satellite` machine, you would
+ssh into the `mothership` and run `git merge` there to complete the
+emulation of `git pull` that were run on `mothership` to pull changes
+made on `satellite`.
`git push origin HEAD:master`::
Push the current branch to the remote ref matching `master` in the