diff --git a/fast b/fast
new file mode 100644
index 0000000..9b6d67e
--- /dev/null
+++ b/fast
@@ -0,0 +1,969 @@
+GIT-PUSH(1)                        Git Manual                       GIT-PUSH(1)
+
+NAME
+       git-push - Update remote refs along with associated objects
+
+SYNOPSIS
+       git push [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
+                  [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-q | --quiet] [-v | --verbose]
+                  [-u | --set-upstream] [-o <string> | --push-option=<string>]
+                  [--[no-]signed|--signed=(true|false|if-asked)]
+                  [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]]
+                  [--no-verify] [<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).
+
+       When the command line does not specify where to push with the
+       <repository> argument, branch.*.remote configuration for the current
+       branch is consulted to determine where to push. If the configuration is
+       missing, it defaults to origin.
+
+       When the command line does not specify what to push with <refspec>...
+       arguments or --all, --mirror, --tags options, the command finds the
+       default <refspec> by consulting remote.*.push configuration, and if it
+       is not found, honors push.default configuration to decide what to push
+       (See git-config(1) for the meaning of push.default).
+
+       When neither the command-line nor the configuration specifies what to
+       push, the default behavior is used, which corresponds to the simple
+       value for push.default: the current branch is pushed to the
+       corresponding upstream branch, but as a safety measure, the push is
+       aborted if the upstream branch does not have the same name as the local
+       one.
+
+OPTIONS
+       <repository>
+           The "remote" repository that is the destination of a push operation.
+           This parameter can be either a URL (see the section GIT URLS below)
+           or the name of a remote (see the section REMOTES below).
+
+       <refspec>...
+           Specify what destination ref to update with what source object. The
+           format of a <refspec> parameter is an optional plus +, followed by
+           the source object <src>, followed by a colon :, followed by the
+           destination ref <dst>.
+
+           The <src> is often the name of the branch you would want to push,
+           but it can be any arbitrary "SHA-1 expression", such as master~4 or
+           HEAD (see gitrevisions(7)).
+
+           The <dst> tells which ref on the remote side is updated with this
+           push. Arbitrary expressions cannot be used here, an actual ref must
+           be named. If git push [<repository>] without any <refspec> argument
+           is set to update some ref at the destination with <src> with
+           remote.<repository>.push configuration variable, :<dst> part can be
+           omitted—such a push will update a ref that <src> normally updates
+           without any <refspec> on the command line. Otherwise, missing :<dst>
+           means to update the same ref as the <src>.
+
+           If <dst> doesn’t start with refs/ (e.g.  refs/heads/master) we will
+           try to infer where in refs/* on the destination <repository> it
+           belongs based on the type of <src> being pushed and whether <dst> is
+           ambiguous.
+
+           •   If <dst> unambiguously refers to a ref on the <repository>
+               remote, then push to that ref.
+
+           •   If <src> resolves to a ref starting with refs/heads/ or
+               refs/tags/, then prepend that to <dst>.
+
+           •   Other ambiguity resolutions might be added in the future, but
+               for now any other cases will error out with an error indicating
+               what we tried, and depending on the
+               advice.pushUnqualifiedRefname configuration (see git-config(1))
+               suggest what refs/ namespace you may have wanted to push to.
+
+           The object referenced by <src> is used to update the <dst> reference
+           on the remote side. Whether this is allowed depends on where in
+           refs/* the <dst> reference lives as described in detail below, in
+           those sections "update" means any modifications except deletes,
+           which as noted after the next few sections are treated differently.
+
+           The refs/heads/* namespace will only accept commit objects, and
+           updates only if they can be fast-forwarded.
+
+           The refs/tags/* namespace will accept any kind of object (as
+           commits, trees and blobs can be tagged), and any updates to them
+           will be rejected.
+
+           It’s possible to push any type of object to any namespace outside of
+           refs/{tags,heads}/*. In the case of tags and commits, these will be
+           treated as if they were the commits inside refs/heads/* for the
+           purposes of whether the update is allowed.
+
+           I.e. a fast-forward of commits and tags outside refs/{tags,heads}/*
+           is allowed, even in cases where what’s being fast-forwarded is not a
+           commit, but a tag object which happens to point to a new commit
+           which is a fast-forward of the commit the last tag (or commit) it’s
+           replacing. Replacing a tag with an entirely different tag is also
+           allowed, if it points to the same commit, as well as pushing a
+           peeled tag, i.e. pushing the commit that existing tag object points
+           to, or a new tag object which an existing commit points to.
+
+           Tree and blob objects outside of refs/{tags,heads}/* will be treated
+           the same way as if they were inside refs/tags/*, any update of them
+           will be rejected.
+
+           All of the rules described above about what’s not allowed as an
+           update can be overridden by adding an the optional leading + to a
+           refspec (or using --force command line option). The only exception
+           to this is that no amount of forcing will make the refs/heads/*
+           namespace accept a non-commit object. Hooks and configuration can
+           also override or amend these rules, see e.g.
+           receive.denyNonFastForwards in git-config(1) and pre-receive and
+           update in githooks(5).
+
+           Pushing an empty <src> allows you to delete the <dst> ref from the
+           remote repository. Deletions are always accepted without a leading +
+           in the refspec (or --force), except when forbidden by configuration
+           or hooks. See receive.denyDeletes in git-config(1) and pre-receive
+           and update in githooks(5).
+
+           The special refspec : (or +: 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.
+
+           tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.
+
+       --all, --branches
+           Push all branches (i.e. refs under refs/heads/); cannot be used with
+           other <refspec>.
+
+       --prune
+           Remove remote branches that don’t have a local counterpart. For
+           example a remote branch tmp will be removed if a local branch with
+           the same name doesn’t exist any more. This also respects refspecs,
+           e.g.  git push --prune remote refs/heads/*:refs/tmp/* would make
+           sure that remote refs/tmp/foo will be removed if refs/heads/foo
+           doesn’t exist.
+
+       --mirror
+           Instead of naming each ref to push, specifies that all 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 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.
+
+       -n, --dry-run
+           Do everything except actually send the updates.
+
+       --porcelain
+           Produce machine-readable output. The output status line for each ref
+           will be tab-separated and sent to stdout instead of stderr. The full
+           symbolic names of the refs will be given.
+
+       -d, --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 refs/tags are pushed, in 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 commit-ish that are reachable from the refs
+           being pushed. This can also be specified with configuration variable
+           push.followTags. For more information, see push.followTags in git-
+           config(1).
+
+       --[no-]signed, --signed=(true|false|if-asked)
+           GPG-sign the push request to update refs on the receiving side, to
+           allow it to be checked by the hooks and/or be logged. If false or
+           --no-signed, no signing will be attempted. If true or --signed, the
+           push will fail if the server does not support signed pushes. If set
+           to if-asked, sign if and only if the server supports signed pushes.
+           The push will also fail if the actual call to gpg --sign fails. See
+           git-receive-pack(1) for the details on the receiving end.
+
+       --[no-]atomic
+           Use an atomic transaction on the remote side if available. Either
+           all refs are updated, or on error, no refs are updated. If the
+           server does not support atomic pushes the push will fail.
+
+       -o <option>, --push-option=<option>
+           Transmit the given string to the server, which passes them to the
+           pre-receive as well as the post-receive hook. The given string must
+           not contain a NUL or LF character. When multiple
+           --push-option=<option> are given, they are all sent to the other
+           side in the order listed on the command line. When no
+           --push-option=<option> is given from the command line, the values of
+           configuration variable push.pushOption are used instead.
+
+       --receive-pack=<git-receive-pack>, --exec=<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.
+
+       --[no-]force-with-lease, --force-with-lease=<refname>,
+       --force-with-lease=<refname>:<expect>
+           Usually, "git push" refuses to update a remote ref that is not an
+           ancestor of the local ref used to overwrite it.
+
+           This option overrides this restriction if the current value of the
+           remote ref is the expected value. "git push" fails otherwise.
+
+           Imagine that you have to rebase what you have already published. You
+           will have to bypass the "must fast-forward" rule in order to replace
+           the history you originally published with the rebased history. If
+           somebody else built on top of your original history while you are
+           rebasing, the tip of the branch at the remote may advance with their
+           commit, and blindly pushing with --force will lose their work.
+
+           This option allows you to say that you expect the history you are
+           updating is what you rebased and want to replace. If the remote ref
+           still points at the commit you specified, you can be sure that no
+           other people did anything to the ref. It is like taking a "lease" on
+           the ref without explicitly locking it, and the remote ref is updated
+           only if the "lease" is still valid.
+
+           --force-with-lease alone, without specifying the details, will
+           protect all remote refs that are going to be updated by requiring
+           their current value to be the same as the remote-tracking branch we
+           have for them.
+
+           --force-with-lease=<refname>, without specifying the expected value,
+           will protect the named ref (alone), if it is going to be updated, by
+           requiring its current value to be the same as the remote-tracking
+           branch we have for it.
+
+           --force-with-lease=<refname>:<expect> will protect the named ref
+           (alone), if it is going to be updated, by requiring its current
+           value to be the same as the specified value <expect> (which is
+           allowed to be different from the remote-tracking branch we have for
+           the refname, or we do not even have to have such a remote-tracking
+           branch when this form is used). If <expect> is the empty string,
+           then the named ref must not already exist.
+
+           Note that all forms other than --force-with-lease=<refname>:<expect>
+           that specifies the expected current value of the ref explicitly are
+           still experimental and their semantics may change as we gain
+           experience with this feature.
+
+           "--no-force-with-lease" will cancel all the previous
+           --force-with-lease on the command line.
+
+           A general note on safety: supplying this option without an expected
+           value, i.e. as --force-with-lease or --force-with-lease=<refname>
+           interacts very badly with anything that implicitly runs git fetch on
+           the remote to be pushed to in the background, e.g.  git fetch origin
+           on your repository in a cronjob.
+
+           The protection it offers over --force is ensuring that subsequent
+           changes your work wasn’t based on aren’t clobbered, but this is
+           trivially defeated if some background process is updating refs in
+           the background. We don’t have anything except the remote tracking
+           info to go by as a heuristic for refs you’re expected to have seen &
+           are willing to clobber.
+
+           If your editor or some other system is running git fetch in the
+           background for you a way to mitigate this is to simply set up
+           another remote:
+
+               git remote add origin-push $(git config remote.origin.url)
+               git fetch origin-push
+
+           Now when the background process runs git fetch origin the references
+           on origin-push won’t be updated, and thus commands like:
+
+               git push --force-with-lease origin-push
+
+           Will fail unless you manually run git fetch origin-push. This method
+           is of course entirely defeated by something that runs git fetch
+           --all, in that case you’d need to either disable it or do something
+           more tedious like:
+
+               git fetch              # update 'master' from remote
+               git tag base master    # mark our base point
+               git rebase -i master   # rewrite some commits
+               git push --force-with-lease=master:base master:master
+
+           I.e. create a base tag for versions of the upstream code that you’ve
+           seen and are willing to overwrite, then rewrite history, and finally
+           force push changes to master if the remote version is still at base,
+           regardless of what your local remotes/origin/master has been updated
+           to in the background.
+
+           Alternatively, specifying --force-if-includes as an ancillary option
+           along with --force-with-lease[=<refname>] (i.e., without saying what
+           exact commit the ref on the remote side must be pointing at, or
+           which refs on the remote side are being protected) at the time of
+           "push" will verify if updates from the remote-tracking refs that may
+           have been implicitly updated in the background are integrated
+           locally before allowing a forced update.
+
+       -f, --force
+           Usually, the command refuses to update a remote ref that is not an
+           ancestor of the local ref used to overwrite it. Also, when
+           --force-with-lease option is used, the command refuses to update a
+           remote ref whose current value does not match what is expected.
+
+           This flag disables these checks, and can cause the remote repository
+           to lose commits; use it with care.
+
+           Note that --force applies to all the refs that are pushed, hence
+           using it with push.default set to matching or with multiple push
+           destinations configured with remote.*.push may overwrite refs other
+           than the current branch (including local refs that are strictly
+           behind their remote counterpart). To force a push to only one
+           branch, use a + in front of the refspec to push (e.g git push origin
+           +master to force a push to the master branch). See the <refspec>...
+           section above for details.
+
+       --[no-]force-if-includes
+           Force an update only if the tip of the remote-tracking ref has been
+           integrated locally.
+
+           This option enables a check that verifies if the tip of the
+           remote-tracking ref is reachable from one of the "reflog" entries of
+           the local branch based in it for a rewrite. The check ensures that
+           any updates from the remote have been incorporated locally by
+           rejecting the forced update if that is not the case.
+
+           If the option is passed without specifying --force-with-lease, or
+           specified along with --force-with-lease=<refname>:<expect>, it is a
+           "no-op".
+
+           Specifying --no-force-if-includes disables this behavior.
+
+       --repo=<repository>
+           This option is equivalent to the <repository> argument. If both are
+           specified, the command-line argument takes precedence.
+
+       -u, --set-upstream
+           For every branch that is up to date or successfully pushed, add
+           upstream (tracking) reference, used by argument-less git-pull(1) and
+           other commands. For more information, see branch.<name>.merge in
+           git-config(1).
+
+       --[no-]thin
+           These options are passed to 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.
+
+       -q, --quiet
+           Suppress all output, including the listing of updated refs, unless
+           an error occurs. Progress is not reported to the standard error
+           stream.
+
+       -v, --verbose
+           Run verbosely.
+
+       --progress
+           Progress status is reported on the standard error stream by default
+           when it is attached to a terminal, unless -q is specified. This flag
+           forces progress status even if the standard error stream is not
+           directed to a terminal.
+
+       --no-recurse-submodules, --recurse-submodules=check|on-demand|only|no
+           May be used to make sure all submodule commits used by the revisions
+           to be pushed are available on a remote-tracking branch. If check is
+           used Git will verify that all submodule commits that changed in the
+           revisions to be pushed are available on at least one remote of the
+           submodule. If any commits are missing the push will be aborted and
+           exit with non-zero status. If on-demand is used all submodules that
+           changed in the revisions to be pushed will be pushed. If on-demand
+           was not able to push all necessary revisions it will also be aborted
+           and exit with non-zero status. If only is used all submodules will
+           be pushed while the superproject is left unpushed. A value of no or
+           using --no-recurse-submodules can be used to override the
+           push.recurseSubmodules configuration variable when no submodule
+           recursion is required.
+
+           When using on-demand or only, if a submodule has 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 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.
+
+GIT URLS
+       In general, URLs contain information about the transport protocol, the
+       address of the remote server, and the path to the repository. Depending
+       on the transport protocol, some of this information may be absent.
+
+       Git supports ssh, git, http, and https protocols (in addition, ftp and
+       ftps can be used for fetching, but this is inefficient and deprecated;
+       do not use them).
+
+       The native transport (i.e. git:// URL) does no authentication and should
+       be used with caution on unsecured networks.
+
+       The following syntaxes may be used with them:
+
+       •   ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>
+
+       •   git://<host>[:<port>]/<path-to-git-repo>
+
+       •   http[s]://<host>[:<port>]/<path-to-git-repo>
+
+       •   ftp[s]://<host>[:<port>]/<path-to-git-repo>
+
+       An alternative scp-like syntax may also be used with the ssh protocol:
+
+       •   [<user>@]<host>:/<path-to-git-repo>
+
+       This syntax is only recognized if there are no slashes before the first
+       colon. This helps differentiate a local path that contains a colon. For
+       example the local path foo:bar could be specified as an absolute path or
+       ./foo:bar to avoid being misinterpreted as an ssh url.
+
+       The ssh and git protocols additionally support ~<username> expansion:
+
+       •   ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>
+
+       •   git://<host>[:<port>]/~<user>/<path-to-git-repo>
+
+       •   [<user>@]<host>:~<user>/<path-to-git-repo>
+
+       For local repositories, also supported by Git natively, the following
+       syntaxes may be used:
+
+       •   /path/to/repo.git/
+
+       •   file:///path/to/repo.git/
+
+       These two syntaxes are mostly equivalent, except when cloning, when the
+       former implies --local option. See git-clone(1) for details.
+
+       git clone, git fetch and git pull, but not git push, will also accept a
+       suitable bundle file. See git-bundle(1).
+
+       When Git doesn’t know how to handle a certain transport protocol, it
+       attempts to use the remote-<transport> remote helper, if one exists. To
+       explicitly request a remote helper, the following syntax may be used:
+
+       •   <transport>::<address>
+
+       where <address> may be a path, a server and path, or an arbitrary
+       URL-like string recognized by the specific remote helper being invoked.
+       See gitremote-helpers(7) 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".
+
+       If you want to rewrite URLs for push only, you can create a
+       configuration section of the form:
+
+                   [url "<actual-url-base>"]
+                           pushInsteadOf = <other-url-base>
+
+       For example, with this:
+
+                   [url "ssh://example.org/"]
+                           pushInsteadOf = git://example.org/
+
+       a URL like "git://example.org/path/to/repo.git" will be rewritten to
+       "ssh://example.org/path/to/repo.git" for pushes, but pulls will still
+       use the original URL.
+
+REMOTES
+       The name of one of the following can be used instead of a URL as
+       <repository> argument:
+
+       •   a remote in the Git configuration file: $GIT_DIR/config,
+
+       •   a file in the $GIT_DIR/remotes directory, or
+
+       •   a file in the $GIT_DIR/branches directory.
+
+       All of these also allow you to omit the refspec from the command line
+       because they each contain a refspec which git will use by default.
+
+   Named remote in configuration file
+       You can choose to provide the name of a remote which you had previously
+       configured using git-remote(1), git-config(1) or even by a manual edit
+       to the $GIT_DIR/config file. The URL of this remote will be used to
+       access the repository. The refspec of this remote will be used by
+       default when you do not provide a refspec on the command line. The entry
+       in the config file would appear like this:
+
+                   [remote "<name>"]
+                           url = <URL>
+                           pushurl = <pushurl>
+                           push = <refspec>
+                           fetch = <refspec>
+
+       The <pushurl> is used for pushes only. It is optional and defaults to
+       <URL>. Pushing to a remote affects all defined pushurls or all defined
+       urls if no pushurls are defined. Fetch, however, will only fetch from
+       the first defined url if multiple urls are defined.
+
+   Named file in $GIT_DIR/remotes
+       You can choose to provide the name of a file in $GIT_DIR/remotes. The
+       URL in this file will be used to access the repository. The refspec in
+       this file will be used as default when you do not provide a refspec on
+       the command line. This file should have the following format:
+
+                   URL: one of the above URL formats
+                   Push: <refspec>
+                   Pull: <refspec>
+
+       Push: lines are used by git push and Pull: lines are used by git pull
+       and git fetch. Multiple Push: and Pull: lines may be specified for
+       additional branch mappings.
+
+   Named file in $GIT_DIR/branches
+       You can choose to provide the name of a file in $GIT_DIR/branches. The
+       URL in this file will be used to access the repository. This file should
+       have the following format:
+
+                   <URL>#<head>
+
+       <URL> is required; #<head> is optional.
+
+       Depending on the operation, git will use one of the following refspecs,
+       if you don’t provide one on the command line. <branch> is the name of
+       this file in $GIT_DIR/branches and <head> defaults to master.
+
+       git fetch uses:
+
+                   refs/heads/<head>:refs/heads/<branch>
+
+       git push uses:
+
+                   HEAD:refs/heads/<head>
+
+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
+               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 to point
+       at commit X to point at commit A. It is a fast-forward.
+
+       But if you try to push, you will attempt to update the branch (that now
+       points at A) with commit B. This does not fast-forward. If you did so,
+       the changes introduced by commit A will be lost, because everybody will
+       now start building on top of B.
+
+       The command by default does not allow an update that is not a
+       fast-forward to prevent such loss of history.
+
+       If you do not want to lose your work (history from X to B) or the work
+       by the other person (history from X to A), you would need to first fetch
+       the history from the repository, create a history that contains changes
+       done by both parties, and push the result back.
+
+       You can perform "git pull", resolve potential conflicts, and "git push"
+       the result. A "git pull" will create a merge commit C between commits A
+       and B.
+
+                 B---C
+                /   /
+            ---X---A
+
+       Updating A with the resulting merge commit will fast-forward and your
+       push will be accepted.
+
+       Alternatively, you can rebase your change between X and B on top of A,
+       with "git pull --rebase", and push the result back. The rebase will
+       create a new commit D that builds the change between X and B on top of
+       A.
+
+                 B   D
+                /   /
+            ---X---A
+
+       Again, updating A with this commit will fast-forward and your push will
+       be accepted.
+
+       There is another common situation where you may encounter
+       non-fast-forward rejection when you try to push, and it is possible even
+       when you are pushing into a repository nobody else pushes into. After
+       you push commit A yourself (in the first picture in this section),
+       replace it with "git commit --amend" to produce commit B, and you try to
+       push it out, because forgot that you have pushed A out already. In such
+       a case, and only if you are certain that nobody in the meantime fetched
+       your earlier commit A (and started building on top of it), you can run
+       "git push --force" to overwrite it. In other words, "git push --force"
+       is a method reserved for a case where you do mean to lose history.
+
+EXAMPLES
+       git push
+           Works like git push <remote>, where <remote> is the current branch’s
+           remote (or origin, if no remote is configured for the current
+           branch).
+
+       git push origin
+           Without additional configuration, pushes the current branch to the
+           configured upstream (branch.<name>.merge configuration variable) if
+           it has the same name as the current branch, and errors out without
+           pushing otherwise.
+
+           The default behavior of this command when no <refspec> is given can
+           be configured by setting the push option of the remote, or the
+           push.default configuration variable.
+
+           For example, to default to pushing only the current branch to origin
+           use git config remote.origin.push HEAD. Any valid <refspec> (like
+           the ones in the examples below) can be configured as the default for
+           git push origin.
+
+       git push origin :
+           Push "matching" branches to origin. See <refspec> in the OPTIONS
+           section above for a description of "matching" branches.
+
+       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 HEAD
+           A handy way to push the current branch to the same name on the
+           remote.
+
+       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 mothership repository; do the
+           same for dev and satellite/dev.
+
+           See the section describing <refspec>... above for a discussion of
+           the matching semantics.
+
+           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
+           origin repository. This form is convenient to push the current
+           branch without thinking about its local name.
+
+       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.
+
+       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 +dev:master
+           Update the origin repository’s master branch with the dev branch,
+           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:
+
+                           o---o---o---A---B  origin/master
+                                    \
+                                     X---Y---Z  dev
+
+           The above command would change the origin repository to
+
+                                     A---B  (unnamed branch)
+                                    /
+                           o---o---o---X---Y---Z  master
+
+           Commits A and B would no longer belong to a branch with a symbolic
+           name, and so would be unreachable. As such, these commits would be
+           removed by a git gc command on the origin repository.
+
+SECURITY
+       The fetch and push protocols are not designed to prevent one side from
+       stealing data from the other repository that was not intended to be
+       shared. If you have private data that you need to protect from a
+       malicious peer, your best option is to store it in another repository.
+       This applies to both clients and servers. In particular, namespaces on a
+       server are not effective for read access control; you should only grant
+       read access to a namespace to clients that you would trust with read
+       access to the entire repository.
+
+       The known attack vectors are as follows:
+
+        1. The victim sends "have" lines advertising the IDs of objects it has
+           that are not explicitly intended to be shared but can be used to
+           optimize the transfer if the peer also has them. The attacker
+           chooses an object ID X to steal and sends a ref to X, but isn’t
+           required to send the content of X because the victim already has it.
+           Now the victim believes that the attacker has X, and it sends the
+           content of X back to the attacker later. (This attack is most
+           straightforward for a client to perform on a server, by creating a
+           ref to X in the namespace the client has access to and then fetching
+           it. The most likely way for a server to perform it on a client is to
+           "merge" X into a public branch and hope that the user does
+           additional work on this branch and pushes it back to the server
+           without noticing the merge.)
+
+        2. As in #1, the attacker chooses an object ID X to steal. The victim
+           sends an object Y that the attacker already has, and the attacker
+           falsely claims to have X and not Y, so the victim sends Y as a delta
+           against X. The delta reveals regions of X that are similar to Y to
+           the attacker.
+
+CONFIGURATION
+       Everything below this line in this section is selectively included from
+       the git-config(1) documentation. The content is the same as what’s found
+       there:
+
+       push.autoSetupRemote
+           If set to "true" assume --set-upstream on default push when no
+           upstream tracking exists for the current branch; this option takes
+           effect with push.default options simple, upstream, and current. It
+           is useful if by default you want new branches to be pushed to the
+           default remote (like the behavior of push.default=current) and you
+           also want the upstream tracking to be set. Workflows most likely to
+           benefit from this option are simple central workflows where all
+           branches are expected to have the same name on the remote.
+
+       push.default
+           Defines the action git push should take if no refspec is given
+           (whether from the command-line, config, or elsewhere). Different
+           values are well-suited for specific workflows; for instance, in a
+           purely central workflow (i.e. the fetch source is equal to the push
+           destination), upstream is probably what you want. Possible values
+           are:
+
+           •   nothing - do not push anything (error out) unless a refspec is
+               given. This is primarily meant for people who want to avoid
+               mistakes by always being explicit.
+
+           •   current - push the current branch to update a branch with the
+               same name on the receiving end. Works in both central and
+               non-central workflows.
+
+           •   upstream - push the current branch back to the branch whose
+               changes are usually integrated into the current branch (which is
+               called @{upstream}). This mode only makes sense if you are
+               pushing to the same repository you would normally pull from
+               (i.e. central workflow).
+
+           •   tracking - This is a deprecated synonym for upstream.
+
+           •   simple - push the current branch with the same name on the
+               remote.
+
+               If you are working on a centralized workflow (pushing to the
+               same repository you pull from, which is typically origin), then
+               you need to configure an upstream branch with the same name.
+
+               This mode is the default since Git 2.0, and is the safest option
+               suited for beginners.
+
+           •   matching - push all branches having the same name on both ends.
+               This makes the repository you are pushing to remember the set of
+               branches that will be pushed out (e.g. if you always push maint
+               and master there and no other branches, the repository you push
+               to will have these two branches, and your local maint and master
+               will be pushed there).
+
+               To use this mode effectively, you have to make sure all the
+               branches you would push out are ready to be pushed out before
+               running git push, as the whole point of this mode is to allow
+               you to push all of the branches in one go. If you usually finish
+               work on only one branch and push out the result, while other
+               branches are unfinished, this mode is not for you. Also this
+               mode is not suitable for pushing into a shared central
+               repository, as other people may add new branches there, or
+               update the tip of existing branches outside your control.
+
+               This used to be the default, but not since Git 2.0 (simple is
+               the new default).
+
+       push.followTags
+           If set to true, enable --follow-tags option by default. You may
+           override this configuration at time of push by specifying
+           --no-follow-tags.
+
+       push.gpgSign
+           May be set to a boolean value, or the string if-asked. A true value
+           causes all pushes to be GPG signed, as if --signed is passed to git-
+           push(1). The string if-asked causes pushes to be signed if the
+           server supports it, as if --signed=if-asked is passed to git push. A
+           false value may override a value from a lower-priority config file.
+           An explicit command-line flag always overrides this config option.
+
+       push.pushOption
+           When no --push-option=<option> argument is given from the command
+           line, git push behaves as if each <value> of this variable is given
+           as --push-option=<value>.
+
+           This is a multi-valued variable, and an empty value can be used in a
+           higher priority configuration file (e.g.  .git/config in a
+           repository) to clear the values inherited from a lower priority
+           configuration files (e.g.  $HOME/.gitconfig).
+
+               Example:
+
+               /etc/gitconfig
+                 push.pushoption = a
+                 push.pushoption = b
+
+               ~/.gitconfig
+                 push.pushoption = c
+
+               repo/.git/config
+                 push.pushoption =
+                 push.pushoption = b
+
+               This will result in only b (a and c are cleared).
+
+       push.recurseSubmodules
+           May be "check", "on-demand", "only", or "no", with the same behavior
+           as that of "push --recurse-submodules". If not set, no is used by
+           default, unless submodule.recurse is set (in which case a true value
+           means on-demand).
+
+       push.useForceIfIncludes
+           If set to "true", it is equivalent to specifying --force-if-includes
+           as an option to git-push(1) in the command line. Adding
+           --no-force-if-includes at the time of push overrides this
+           configuration setting.
+
+       push.negotiate
+           If set to "true", attempt to reduce the size of the packfile sent by
+           rounds of negotiation in which the client and the server attempt to
+           find commits in common. If "false", Git will rely solely on the
+           server’s ref advertisement to find commits in common.
+
+       push.useBitmaps
+           If set to "false", disable use of bitmaps for "git push" even if
+           pack.useBitmaps is "true", without preventing other git operations
+           from using bitmaps. Default is true.
+
+GIT
+       Part of the git(1) suite
+
+Git 2.48.1                         01/14/2025                       GIT-PUSH(1)