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