git-push man page on YellowDog

Man page or keyword search:  
man Server   18644 pages
apropos Keyword Search (all sections)
Output format
YellowDog logo
[printable version]

GIT-PUSH(1)			  Git Manual			   GIT-PUSH(1)

NAME
       git-push - Update remote refs along with associated objects

SYNOPSIS
       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
       git-receive-pack(1).

OPTIONS
       <repository>
	      The "remote" repository that is destination of a push operation.
	      See the section 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 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.

	      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 "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>.

	      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.

       --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.

       --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.

GIT URLS
       One of the following notations can be used to name the remote
       repository:

       ·  rsync://host.xz/path/to/repo.git/

       ·  http://host.xz/path/to/repo.git/

       ·  https://host.xz/path/to/repo.git/

       ·  git://host.xz/path/to/repo.git/

       ·  git://host.xz/~user/path/to/repo.git/

       ·  ssh://[user@]host.xz[:port]/path/to/repo.git/

       ·  ssh://[user@]host.xz/path/to/repo.git/

       ·  ssh://[user@]host.xz/~user/path/to/repo.git/

       ·  ssh://[user@]host.xz/~/path/to/repo.git

	  SSH is the default transport protocol over the network. You can
	  optionally specify which user to log-in as, and an alternate,
	  scp-like syntax is also supported. Both syntaxes support username
	  expansion, as does the native git protocol, but only the former
	  supports port specification. The following three are identical to
	  the last three above, respectively:

       ·  [user@]host.xz:/path/to/repo.git/

       ·  [user@]host.xz:~user/path/to/repo.git/

       ·  [user@]host.xz:path/to/repo.git

	  To sync with a local directory, you can use:

       ·  /path/to/repo.git/

       ·  file:///path/to/repo.git/

	  They are mostly equivalent, except when cloning. See git-clone(1)
	  for details.

	  If there are a large number of similarly-named remote repositories
	  and you want to use a different format for them (such that the URLs
	  you use will be rewritten into URLs that work), you can create a
	  configuration section of the form:

		  [url "<actual url base>"]
			  insteadOf = <other url base>

	  For example, with this:

		  [url "git://git.host.xz/"]
			  insteadOf = host.xz:/path/to/
			  insteadOf = work:

	  a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will
	  be rewritten in any context that takes a URL to be
	  "git://git.host.xz/repo.git".

REMOTES
       In addition to the above, as a short-hand, the name of a file in
       $GIT_DIR/remotes directory can be given; the named file should be in
       the following format:

	       URL: one of the above URL format
	       Push: <refspec>
	       Pull: <refspec>

       Then such a short-hand is specified in place of <repository> without
       <refspec> parameters on the command line, <refspec> specified on Push:
       lines or Pull: lines are used for git-push and git-fetch/git-pull,
       respectively. Multiple Push: and Pull: lines may be specified for
       additional branch mappings.

       Or, equivalently, in the $GIT_DIR/config (note the use of fetch instead
       of Pull:):

	       [remote "<remote>"]
		       url = <url>
		       push = <refspec>
		       fetch = <refspec>

       The name of a file in $GIT_DIR/branches directory can be specified as
       an older notation short-hand; the named file should contain a single
       line, a URL in one of the above formats, optionally followed by a hash
       # and the name of remote head (URL fragment notation).
       $GIT_DIR/branches/<remote> file that stores a <url> without the
       fragment is equivalent to have this in the corresponding file in the
       $GIT_DIR/remotes/ directory.

	       URL: <url>
	       Pull: refs/heads/master:<remote>

       while having <url>#<head> is equivalent to

	       URL: <url>
	       Pull: refs/heads/<head>:<remote>

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 git(7) suite

Git 1.5.5.2			  10/21/2008			   GIT-PUSH(1)
[top]

List of man pages available for YellowDog

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net