Code

Documentation: Add create-ignore to git svn manual
[git.git] / Documentation / git-push.txt
index b8003c63c7e51dc1e3907645b267805dfb5f38d6..05859491378243639e81c9c8ab7deffb90d83d07 100644 (file)
@@ -20,7 +20,7 @@ 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 gitlink:git-receive-pack[1].
+documentation for linkgit:git-receive-pack[1].
 
 
 OPTIONS
@@ -35,21 +35,22 @@ OPTIONS
        by the source ref, followed by a colon `:`, followed by
        the destination ref.
 +
-The <src> side can be an
-arbitrary "SHA1 expression" that can be used as an
-argument to `git-cat-file -t`.  E.g. `master~4` (push
-four parents before the current master head).
+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>.  If
-the optional plus `+` is used, the remote ref is updated
+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.
 +
 Note: 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), then all the
-heads that exist both on the local side and on the remote
-side are updated.
+corresponding remotes file---see below), then "matching" heads are
+pushed: 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.
 +
 `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
 +
@@ -108,6 +109,55 @@ the remote repository.
 
 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
 --------
@@ -116,7 +166,8 @@ 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.
+       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
@@ -130,9 +181,10 @@ git push origin master:satellite/master::
 
 git push origin master:refs/heads/experimental::
        Create the branch `experimental` in the `origin` repository
-       by copying the current `master` branch.  This form is usually
-       needed to create a new branch in the remote repository as
-       there is no `experimental` branch to match.
+       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
 ------
@@ -145,4 +197,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
 
 GIT
 ---
-Part of the gitlink:git[7] suite
+Part of the linkgit:git[7] suite