NAME
----
-git-push - Update remote refs along with associated objects.
+git-push - Update remote refs along with associated objects
SYNOPSIS
--------
-'git-push' [--all] [--force] <repository> <refspec>...
+[verse]
+'git push' [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+ [--repo=<repository>] [-f | --force] [-v | --verbose]
+ [<repository> <refspec>...]
DESCRIPTION
-----------
Updates remote refs using local refs, while sending objects
necessary to complete the given refs.
+You can make interesting things happen to a repository
+every time you push into it, by setting up 'hooks' there. See
+documentation for linkgit:git-receive-pack[1].
+
OPTIONS
-------
-include::pull-fetch-param.txt[]
+<repository>::
+ The "remote" repository that is destination of a push
+ operation. See the section <<URLS,GIT URLS>> below.
+
+<refspec>...::
+ The canonical format of a <refspec> parameter is
+ `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
+ by the source ref, followed by a colon `:`, followed by
+ the destination ref.
++
+The <src> side represents the source branch (or arbitrary
+"SHA1 expression", such as `master~4` (four parents before the
+tip of `master` branch); see linkgit:git-rev-parse[1]) that you
+want to push. The <dst> side represents the destination location.
++
+The local ref that matches <src> is used
+to fast forward the remote ref that matches <dst> (or, if no <dst> was
+specified, the same ref that <src> referred to locally). If
+the optional leading plus `+` is used, the remote ref is updated
+even if it does not result in a fast forward update.
++
+`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
++
+A parameter <ref> without a colon pushes the <ref> from the source
+repository to the destination repository under the same name.
++
+Pushing an empty <src> allows you to delete the <dst> ref from
+the remote repository.
++
+The special refspec `:` (or `+:` to allow non-fast forward updates)
+directs git to push "matching" heads: for every head that exists on
+the local side, the remote side is updated if a head 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).
+
+--all::
+ Instead of naming each ref to push, specifies that all
+ refs under `$GIT_DIR/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
+ 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 force updated on the remote end, and deleted refs
+ will be removed from the remote end. This is the default
+ if the configuration option `remote.<remote>.mirror` is
+ set.
+
+--dry-run::
+ Do everything except actually send the updates.
+
+--tags::
+ All refs under `$GIT_DIR/refs/tags` are pushed, in
+ addition to refspecs explicitly listed on the command
+ line.
+
+--receive-pack=<git-receive-pack>::
+ Path to the 'git-receive-pack' program on the remote
+ end. Sometimes useful when pushing to a remote
+ repository over ssh, and you do not have the program in
+ a directory on the default $PATH.
+
+--exec=<git-receive-pack>::
+ Same as \--receive-pack=<git-receive-pack>.
+
+-f::
+--force::
+ Usually, the command refuses to update a remote ref that is
+ 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.
+
+--repo=<repository>::
+ This option is only relevant if no <repository> argument is
+ 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
+ can be used to override the name "origin". In other words,
+ the difference between these two commands
++
+--------------------------
+git push public #1
+git push --repo=public #2
+--------------------------
++
+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'.
+
+--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.
+
+-v::
+--verbose::
+ Run verbosely.
+
+include::urls-remotes.txt[]
+
+OUTPUT
+------
+The output of "git push" depends on the transport method used; this
+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
+representing the status of a single ref. Each line is of the form:
+
+-------------------------------
+ <flag> <summary> <from> -> <to> (<reason>)
+-------------------------------
+
+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).
+
+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).
+
+from::
+ The name of the local ref being pushed, minus its
+ `refs/<type>/` prefix. In the case of deletion, the
+ name of the local ref is omitted.
+
+to::
+ The name of the remote ref being updated, minus its
+ `refs/<type>/` prefix.
+
+reason::
+ A human-readable explanation. In the case of successfully pushed
+ refs, no explanation is needed. For a failed ref, the reason for
+ failure is described.
+
+Examples
+--------
+
+git push origin master::
+ Find a ref that matches `master` in the source repository
+ (most likely, it would find `refs/heads/master`), and update
+ the same ref (e.g. `refs/heads/master`) in `origin` repository
+ with it. If `master` did not exist remotely, it would be
+ created.
+
+git push origin :experimental::
+ Find a ref that matches `experimental` in the `origin` repository
+ (e.g. `refs/heads/experimental`), and delete it.
+
+git push origin 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
+ do the same for `dev` and `satellite/dev`.
+
+git push origin master:refs/heads/experimental::
+ Create the branch `experimental` in the `origin` repository
+ by copying the current `master` branch. This form is only
+ needed to create a new branch or tag in the remote repository when
+ the local name and the remote name are different; otherwise,
+ the ref name on its own will work.
Author
------
-Written by Junio C Hamano <junkio@cox.net>
+Written by Junio C Hamano <gitster@pobox.com>, later rewritten in C
+by Linus Torvalds <torvalds@osdl.org>
Documentation
--------------
GIT
---
-Part of the gitlink:git[7] suite
-
+Part of the linkgit:git[1] suite