All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: git@vger.kernel.org, pclouds@gmail.com, sunshine@sunshineco.com,
	mhagger@alum.mit.edu, ronniesahlberg@gmail.com,
	jrnieder@gmail.com, Ronnie Sahlberg <sahlberg@google.com>
Subject: Re: [PATCHv12 06/10] receive-pack.c: negotiate atomic push support
Date: Thu, 08 Jan 2015 15:51:23 -0800	[thread overview]
Message-ID: <xmqq7fwwesqs.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1420687404-13997-7-git-send-email-sbeller@google.com> (Stefan Beller's message of "Wed, 7 Jan 2015 19:23:20 -0800")

Stefan Beller <sbeller@google.com> writes:

> From: Ronnie Sahlberg <sahlberg@google.com>
>
> This adds the atomic protocol option to allow
> receive-pack to inform the client that it has
> atomic push capability.
>
> This commit makes the functionality introduced
> in the previous commits go live for the serving
> side. The changes in documentation reflect the
> protocol capabilities of the server.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>
> Notes:
>     v10, v11, v12:
>     * no changes
>     
>     v9:
>      This was once part of "[PATCH 1/7] receive-pack.c:
>      add protocol support to negotiate atomic-push"
>      but now it only touches the receive-pack.c part
>      and doesn't bother with the send-pack part any more.
>      That is done in a later patch, when send-pack actually
>      learns all the things it needs to know about the
>      atomic push option.
>     
>      We can configure the remote if it wants to advertise
>      atomicity!
>     
>     All previous notes were lost due to my glorious
>     capability to operate git rebase.

The list archive remembers if you really care ;-)

I ran out of time and concentration for today to read it through at
this step; among things I saw, nothing looked wrong so far, and at
this step everything looks ready to be tested almost.

Looking good.

>
>  Documentation/technical/protocol-capabilities.txt | 13 +++++++++++--
>  builtin/receive-pack.c                            | 11 +++++++++++
>  2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt
> index 6d5424c..4f8a7bf 100644
> --- a/Documentation/technical/protocol-capabilities.txt
> +++ b/Documentation/technical/protocol-capabilities.txt
> @@ -18,8 +18,9 @@ was sent.  Server MUST NOT ignore capabilities that client requested
>  and server advertised.  As a consequence of these rules, server MUST
>  NOT advertise capabilities it does not understand.
>  
> -The 'report-status', 'delete-refs', 'quiet', and 'push-cert' capabilities
> -are sent and recognized by the receive-pack (push to server) process.
> +The 'atomic', 'report-status', 'delete-refs', 'quiet', and 'push-cert'
> +capabilities are sent and recognized by the receive-pack (push to server)
> +process.
>  
>  The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized
>  by both upload-pack and receive-pack protocols.  The 'agent' capability
> @@ -244,6 +245,14 @@ respond with the 'quiet' capability to suppress server-side progress
>  reporting if the local progress reporting is also being suppressed
>  (e.g., via `push -q`, or if stderr does not go to a tty).
>  
> +atomic
> +------
> +
> +If the server sends the 'atomic' capability it is capable of accepting
> +atomic pushes. If the pushing client requests this capability, the server
> +will update the refs in one atomic transaction. Either all refs are
> +updated or none.
> +
>  allow-tip-sha1-in-want
>  ----------------------
>  
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index 362d33f..4c069c5 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -37,6 +37,7 @@ static int receive_fsck_objects = -1;
>  static int transfer_fsck_objects = -1;
>  static int receive_unpack_limit = -1;
>  static int transfer_unpack_limit = -1;
> +static int advertise_atomic_push = 1;
>  static int unpack_limit = 100;
>  static int report_status;
>  static int use_sideband;
> @@ -159,6 +160,11 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
>  		return 0;
>  	}
>  
> +	if (strcmp(var, "receive.advertiseatomic") == 0) {
> +		advertise_atomic_push = git_config_bool(var, value);
> +		return 0;
> +	}
> +
>  	return git_default_config(var, value, cb);
>  }
>  
> @@ -174,6 +180,8 @@ static void show_ref(const char *path, const unsigned char *sha1)
>  
>  		strbuf_addstr(&cap,
>  			      "report-status delete-refs side-band-64k quiet");
> +		if (advertise_atomic_push)
> +			strbuf_addstr(&cap, " atomic");
>  		if (prefer_ofs_delta)
>  			strbuf_addstr(&cap, " ofs-delta");
>  		if (push_cert_nonce)
> @@ -1263,6 +1271,9 @@ static struct command *read_head_info(struct sha1_array *shallow)
>  				use_sideband = LARGE_PACKET_MAX;
>  			if (parse_feature_request(feature_list, "quiet"))
>  				quiet = 1;
> +			if (advertise_atomic_push
> +			    && parse_feature_request(feature_list, "atomic"))
> +				use_atomic = 1;
>  		}
>  
>  		if (!strcmp(line, "push-cert")) {

  reply	other threads:[~2015-01-08 23:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-08  3:23 [PATCHv12 00/10] atomic pushes Stefan Beller
2015-01-08  3:23 ` [PATCHv12 01/10] receive-pack.c: shorten the execute_commands loop over all commands Stefan Beller
2015-01-08  3:23 ` [PATCHv12 02/10] receive-pack.c: die instead of error in case of possible future bug Stefan Beller
2015-01-08  3:23 ` [PATCHv12 03/10] receive-pack.c: move iterating over all commands outside execute_commands Stefan Beller
2015-01-08  3:23 ` [PATCHv12 04/10] receive-pack.c: move transaction handling in a central place Stefan Beller
2015-01-08  3:23 ` [PATCHv12 05/10] receive-pack.c: add execute_commands_atomic function Stefan Beller
2015-01-08  3:23 ` [PATCHv12 06/10] receive-pack.c: negotiate atomic push support Stefan Beller
2015-01-08 23:51   ` Junio C Hamano [this message]
2015-01-12 23:29   ` Eric Sunshine
2015-01-12 23:43     ` Stefan Beller
2015-01-13  0:08     ` Junio C Hamano
2015-01-08  3:23 ` [PATCHv12 07/10] send-pack: rename ref_update_to_be_sent to check_to_send_update Stefan Beller
2015-01-08  3:23 ` [PATCHv12 08/10] send-pack.c: add --atomic command line argument Stefan Beller
2015-01-12 21:57   ` Junio C Hamano
2015-01-08  3:23 ` [PATCHv12 09/10] push.c: add an --atomic argument Stefan Beller
2015-01-08  3:23 ` [PATCHv12 10/10] t5543-atomic-push.sh: add basic tests for atomic pushes Stefan Beller
2015-01-12 23:40   ` Eric Sunshine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq7fwwesqs.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --cc=pclouds@gmail.com \
    --cc=ronniesahlberg@gmail.com \
    --cc=sahlberg@google.com \
    --cc=sbeller@google.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.