a
"push.recurseSubmodules={on-demand,only}" or "submodule.recurse" configuration,
further recursion will occur. In this case, "only" is treated as "on-demand".

--[no-]verify::
	Toggle the pre-push hook (see linkgit:githooks[5]).  The
	default is --verify, giving the hook a chance to prevent the
	push.  With --no-verify, the hook is bypassed completely.

-4::
--ipv4::
	Use IPv4 addresses only, ignoring IPv6 addresses.

-6::
--ipv6::
	Use IPv6 addresses only, ignoring IPv4 addresses.

include::urls-remotes.adoc[]

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

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:
(space);; for a successfully pushed fast-forward;
`+`;; 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 failed update, more details are given:
+
--
rejected::
	Git did not try to send the ref at all, typically because it
	is not a fast-forward and you did not force the update.

remote rejected::
	The remote end refused the update.  Usually caused by a hook
	on the remote side, or because the remote repository has one
	of the following safety options in effect:
	`receive.denyCurrentBranch` (for pushes to the checked out
	branch), `receive.denyNonFastForwards` (for forced
	non-fast-forward updates), `receive.denyDeletes` or
	`receive.denyDeleteCurrent`.  See linkgit:git-config[1].

remote failure::
	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.

NOTE ABOUT FAST-FORWARDS
------------------------

When an update changes a branch (or more in general, a ref) that used to
point at commit A to point at another commit B, it is called a
fast-forward update if and only if B is a descendant of A.

In a fast-forward update from A to B, the set of commits that the original
commit A built on top of is a subset of the commits the new commit B
builds on top of.  Hence, it does not lose any history.

In contrast, a non-fast-forward update will lose history.  For example,
suppose you and somebody else started at the same commit X, and you built
a history leading to commit B while the other person built a history
leading to commit A.  The history looks like this:

----------------

      B
     /
 ---X---A

----------------

Further suppose that the other person already pushed changes leading to A
back to the original repository from which you two obtained the original
commit X.

The push done by the other person updated the branch that used