push: --follow-tags

[thirdparty/git.git] / Documentation / git-push.txt

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 6d19d59ce5a3a683c1af3b0541a5746faba116f9..40377ba4589bd4a6a91088210b368372df97e988 100644 (file)
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
 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>...]]
 
@@ -111,6 +111,12 @@ no `push.default` configuration variable is set.
        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
@@ -385,11 +391,23 @@ the ones in the examples below) can be configured as the default for
        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