--------
[verse]
'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
- [--repo=<repository>] [-f | --force] [-v | --verbose]
- [<repository> <refspec>...]
+ [--repo=<repository>] [-f | --force] [-v | --verbose] [-u | --set-upstream]
+ [<repository> [<refspec>...]]
DESCRIPTION
-----------
+
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
-`HEAD` (see linkgit:git-rev-parse[1]).
+`HEAD` (see linkgit:gitrevisions[7]).
+
The <dst> tells which ref on the remote side is updated with this
push. Arbitrary expressions cannot be used here, an actual ref must
+
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 `{plus}`,
+update can fast-forward <dst>. By having the optional leading `{plus}`,
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
+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>`.
Pushing an empty <src> allows you to delete the <dst> ref from
the remote repository.
+
-The special refspec `:` (or `{plus}:` to allow non-fast forward updates)
+The special refspec `:` (or `{plus}:` to allow non-fast-forward updates)
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
--all::
Instead of naming each ref to push, specifies that all
- refs under `$GIT_DIR/refs/heads/` be pushed.
+ refs under `refs/heads/` be pushed.
--mirror::
Instead of naming each ref to push, specifies that all
- refs under `$GIT_DIR/refs/` (which includes but is not
+ refs under `refs/` (which includes but is not
limited to `refs/heads/`, `refs/remotes/`, and `refs/tags/`)
be mirrored to the remote repository. Newly created local
refs will be pushed to the remote end, locally updated refs
will be tab-separated and sent to stdout instead of stderr. The full
symbolic names of the refs will be given.
+--delete::
+ All listed refs are deleted from the remote repository. This is
+ the same as prefixing all refs with a colon.
+
--tags::
- All refs under `$GIT_DIR/refs/tags` are pushed, in
+ All refs under `refs/tags` are pushed, in
addition to refspecs explicitly listed on the command
line.
--repo=<repository>::
This option is only relevant if no <repository> argument is
- passed in the invocation. In this case, 'git-push' derives the
+ passed in the invocation. In this case, 'git push' derives the
remote name from the current branch: If it tracks a remote
branch, then that remote repository is pushed to. Otherwise,
the name "origin" is used. For this latter case, this option
+
is that #1 always pushes to "public" whereas #2 pushes to "public"
only if the current branch does not track a remote branch. This is
-useful if you write an alias or script around 'git-push'.
+useful if you write an alias or script around 'git push'.
+
+-u::
+--set-upstream::
+ For every branch that is up to date or successfully pushed, add
+ upstream (tracking) reference, used by argument-less
+ linkgit:git-pull[1] and other commands. For more information,
+ see 'branch.<name>.merge' in linkgit:git-config[1].
--thin::
--no-thin::
- These options are passed to 'git-send-pack'. Thin
- transfer spends extra cycles to minimize the number of
- objects to be sent and meant to be used on slower connection.
+ 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
+ \--thin.
+
+-q::
+--quiet::
+ Suppress all output, including the listing of updated refs,
+ unless an error occurs. Progress is not reported to the standard
+ error stream.
-v::
--verbose::
Run verbosely.
--q::
---quiet::
- Suppress all output, including the listing of updated refs,
- unless an error occurs.
+--progress::
+ Progress status is reported on the standard error stream
+ by default when it is attached to a terminal, unless -q
+ is specified. This flag forces progress status even if the
+ standard error stream is not directed to a terminal.
include::urls-remotes.txt[]
<flag> \t <from>:<to> \t <summary> (<reason>)
-------------------------------
+The status of up-to-date refs is shown only if --porcelain or --verbose
+option is used.
+
flag::
- A single character indicating the status of the ref. This is
- blank for a successfully pushed ref, `!` for a ref that was
- rejected or failed to push, and '=' for a ref that was up to
- date and did not need pushing (note that the status of up to
- date refs is shown only when `git push` is running verbosely).
+ A single character indicating the status of the ref:
+(space);; for a successfully pushed fast-forward;
+`{plus}`;; for a successful forced update;
+`-`;; for a successfully deleted ref;
+`*`;; for a successfully pushed new ref;
+`!`;; for a ref that was rejected or failed to push; and
+`=`;; for a ref that was up to date and did not need pushing.
summary::
For a successfully pushed ref, the summary shows the old and new
values of the ref in a form suitable for using as an argument to
`git log` (this is `<old>..<new>` in most cases, and
- `<old>...<new>` for forced non-fast forward updates). For a
- failed update, more details are given for the failure.
- The string `rejected` indicates that git did not try to send the
- ref at all (typically because it is not a fast forward). The
- string `remote rejected` indicates that the remote end refused
- the update; this rejection is typically caused by a hook on the
- remote side. The string `remote failure` indicates that the
- remote end did not report the successful update of the ref
- (perhaps because of a temporary error on the remote side, a
- break in the network connection, or other transient error).
+ `<old>\...<new>` for forced non-fast-forward updates).
++
+For a failed update, more details are given:
++
+--
+rejected::
+ Git did not try to send the ref at all, typically because it
+ is not a fast-forward and you did not force the update.
+
+remote rejected::
+ The remote end refused the update. Usually caused by a hook
+ on the remote side, or because the remote repository has one
+ of the following safety options in effect:
+ `receive.denyCurrentBranch` (for pushes to the checked out
+ branch), `receive.denyNonFastForwards` (for forced
+ non-fast-forward updates), `receive.denyDeletes` or
+ `receive.denyDeleteCurrent`. See linkgit:git-config[1].
+
+remote failure::
+ The remote end did not report the successful update of the ref,
+ perhaps because of a temporary error on the remote side, a
+ break in the network connection, or other transient error.
+--
from::
The name of the local ref being pushed, minus its
git push origin {plus}dev:master::
Update the origin repository's master branch with the dev branch,
- allowing non-fast forward updates. *This can leave unreferenced
+ allowing non-fast-forward updates. *This can leave unreferenced
commits dangling in the origin repository.* Consider the
- following situation, where a fast forward is not possible:
+ following situation, where a fast-forward is not possible:
+
----
o---o---o---A---B origin/master