Merge branch 'maint'
[gitweb.git] / Documentation / git-push.txt
index 37c88953d1a08c0498c794aeb4d0d38eac8a36db..49b6bd9d925f9150a4aaf2f2c4d7439503863d05 100644 (file)
@@ -10,7 +10,7 @@ SYNOPSIS
 --------
 [verse]
 'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
-          [--repo=<repository>] [-f | --force] [-v | --verbose]
+          [--repo=<repository>] [-f | --force] [-v | --verbose] [-u | --set-upstream]
           [<repository> <refspec>...]
 
 DESCRIPTION
@@ -50,9 +50,9 @@ 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 `{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>`.
@@ -60,7 +60,7 @@ EXAMPLES below for details.
 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
@@ -69,11 +69,11 @@ 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.
+       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
@@ -91,8 +91,12 @@ nor in any Push line of the corresponding remotes file---see below).
        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.
 
@@ -112,7 +116,7 @@ nor in any Push line of the corresponding remotes file---see below).
 
 --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
@@ -126,13 +130,21 @@ 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'.
+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.
 
 -v::
 --verbose::
@@ -165,21 +177,26 @@ If --porcelain is used, then each line of the output is of the form:
  <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
+       `<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
+       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
@@ -347,9 +364,9 @@ git push origin :experimental::
 
 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