receive-pack.c: add protocol support to negotiate atomic-push

This adds support to the protocol between send-pack and receive-pack to
* allow receive-pack to inform the client that it has atomic push capability
* allow send-pack to request atomic push back.

There is currently no setting in send-pack to actually request that atomic
pushes are to be used yet. This only adds protocol capability not ability
for the user to activate it.

Change-Id: I37530b96c8f5288130ee5e05395a8cda03ba470b
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
send-pack.c: add an --atomic-push command line argument

This adds support to send-pack to to negotiate and use atomic pushes
iff the server supports it. Atomic pushes are activated by a new command
line flag --atomic-push.

In order to do this we also need to change the semantics for send_pack()
slightly. The existing send_pack() function actually don't sent all the
refs back to the server when multiple refs are involved, for example
when using --all. Several of the failure modes for pushes can already be
detected locally in the send_pack client based on the information from the
initial server side list of all the refs as generated by receive-pack.
Any such refs that we thus know would fail to push are thus pruned from
the list of refs we send to the server to update.

For atomic pushes, we have to deal thus with both failures that are detected
locally as well as failures that are reported back from the server. In order
to do so we treat all local failures as push failures too.

We introduce a new status code REF_STATUS_ATOMIC_PUSH_FAILED so we can
flag all refs that we would normally have tried to push to the server
but we did not due to local failures. This is to improve the error message
back to the end user to flag that "these refs failed to update since the
atomic push operation failed."

Change-Id: I1444d896f6bc6b6f1078b893b5a5b5186b445159
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
receive-pack.c: use a single transaction when atomic-push is negotiated

Update receive-pack to use an atomic transaction iff the client negotiated
that it wanted atomic-push.
This leaves the default behavior to be the old non-atomic one ref at a
time update. This is to cause as little disruption as possible to existing
clients. It is unknown if there are client scripts that depend on the old
non-atomic behavior so we make it opt-in for now.

Later patch in this series also adds a configuration variable where you can
override the atomic push behavior on the receiving repo and force it
to use atomic updates always.

If it turns out over time that there are no client scripts that depend on the
old behavior we can change git to default to use atomic pushes and instead
offer an opt-out argument for people that do not want atomic pushes.

Change-Id: I233594fbff357383b794230672beab7933e3ce0f
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
push.c: add an --atomic-push argument

Add a command line argument to the git push command to request atomic
pushes.

Change-Id: I2e17cbd4d53f7f8bd55f0477363af6173522e09a
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
t5543-atomic-push.sh: add basic tests for atomic pushes

Change-Id: I16bb0b85a7f780e1e5b55b90d13784662d20e701
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
receive-pack.c: add a receive.preferatomicpush configuration variable

Add receive.preferatomicpush setting to receive-pack.c. This triggers
a new capability "prefer-atomic-push" to be sent back to the send-pack
client, requesting the client, if it supports it, to request
an atomic push.

This is an alternative way to trigger an atomic push instead of having
to rely of the user using the --atomic-push command line argument.
For backward compatibility, this is only a hint to the client that is should
request atomic pushes if it can. Old clients that do not support atomic pushes
will just ignore this capability and use a normal push.

The reason we need to signal this capability back to the client is due
to that send_pack() has push failure modes where it will detect that
certain refs can not be pushed and fail them early. Those refs would not
even be sent by the client unless atomic-pushes are activated.
This means that IF we activate this feature from the server side we must
tell the client to not fail refs early and use an atomic push. We can not
enforce this on the server side only.

Change-Id: Ic3b0ee526f246b78c21d49d861af3a4d38dba1e5
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: add an err argument to create_reflog

Add err argument to create_reflog that can explain the reason for a
failure. This then eliminates the need to manage errno through this
function since we can just add strerror(errno) to the err string when
meaningful. No callers relied on errno from this function for anything
else than the error message.

log_ref_write is a private function that calls create_reflog. Update
this function to also take an err argument and pass it back to the caller.
This again eliminates the need to manage errno in this function.

Update the private function write_sha1_update_reflog to also take an
err argument.

Change-Id: I0a69959b47f9261e77beac1d1923ad408eee48f9
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: add an err argument to create_symref

Change-Id: I581c35aee25daa93be47febddc0f5aca675d2d0c
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>