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.

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

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.

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.

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

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 is triggers
a new capability "prefer-atomic-push" to be sent back to the send-pack
client, requesting that 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 and will later only send
a subset of all refs to the server. For atomic pushes we want the push to fail
if either the refs failed early in the client or if the refs failed when sent
to the server. This means that we can not do the atomic-push logic unilaterally
in the server but need the client to cooperate.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: add a public is_branch function

Both refs.c and fsck.c have their own private copies of the is_branch function.
Delete the is_branch function from fsck.c and make the version in refs.c
public.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
refs.c: create a public function for is_refname_available

Export a generic is_refname_available() function. We will need this
as a public shared function later when we add additional refs backends
since we want to keep using the same rules for ref naming across
all backends.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs-be-files.c: rename refs to refs-be-files

Rename refs.c to refs-be-files.c to indicate that this file now
holds the implementation for the files based refs backend.
A smaller portion of the code in this file is backend agnostic and will
be moved to a a new refs.c file that will hold all the common refs code
that is shared across all backends.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: add a new refs.c file to hold all common refs code

Create a new erfs.c file that will be used to hold all the refs
code that is backend agnostic and will be shared across all backends.

The reason we renamed everything to refs-be-files.c in the previous patch
and now start moving the common code back to the new refs.c file
instead of the other way around is the etive volumes of code.

With the ref_cache, packed refs and loose ref handling that are all
part of the files based implementation the backend specific part
of the old refs.c file is several times larger than the backend agnostic
part. Therefore it makes more sense to first rename everything to be
part of the files based backend and then move the parts that can be used
as common code back to refs.c.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: move update_ref to refs.c

This change moves update_ref() to the refs.c file since this function
does not contain any backend specific code.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: move delete_ref to the common code

This change moves delete_ref() to the refs.c file since this function
does not contain any backend specific code.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: move rename_ref to the common code

This change moves rename_ref() to the refs.c file since this function
does not contain any backend specific code.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: move read_ref_at to the common refs file

This change moves read_ref_at() to the refs.c file since this function
does not contain any backend specific code.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: move the hidden refs functions to the common code

This change moves the hidden refs functions to the refs.c file since
these functions do not contain any backend specific code.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: move dwim and friend functions to the common refs code

These functions do not contain any backend specific code so we can move
them to the common code and share across all backends.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: move warn_if_dangling_symref* to the common code

These functions do not use any backend specific code so we can move
them to the common code.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: move read_ref, read_ref_full and ref_exists to the common code

These functions do not depend on the backend implementation so we
can move them to the common code.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: move resolve_refdup to common

This function can be shared across all refs backends so move it
to the common code.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refs.c: move check_refname_component to the common code

This function does not contain any backend specific code so we
can move it to the common code.

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