diff options
Diffstat (limited to 'Documentation/git-push.txt')
| -rw-r--r-- | Documentation/git-push.txt | 206 |
1 files changed, 206 insertions, 0 deletions
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt new file mode 100644 index 0000000000..89e0049bce --- /dev/null +++ b/Documentation/git-push.txt @@ -0,0 +1,206 @@ +git-push(1) +=========== + +NAME +---- +git-push - Update remote refs along with associated objects + + +SYNOPSIS +-------- +[verse] +'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] + [--repo=all] [-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 +------- +<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 `+`, 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/heads/` and `$GIT_DIR/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=<repo>:: + When no repository is specified the command defaults to + "origin"; this overrides it. + +--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:: + Find a ref that matches `master` in the source repository + (most likely, it would find `refs/heads/master`), and update + the ref that matches `satellite/master` (most likely, it would + be `refs/remotes/satellite/master`) in `origin` repository with it. + +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>, later rewritten in C +by Linus Torvalds <torvalds@osdl.org> + +Documentation +-------------- +Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. + +GIT +--- +Part of the linkgit:git[1] suite |