public inbox for git@vger.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$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=jrnieder@gmail$(echo .)com \
    --cc=mhagger@alum$(echo .)mit.edu \
    --cc=pclouds@gmail$(echo .)com \
    --cc=ronniesahlberg@gmail$(echo .)com \
    --cc=sahlberg@google$(echo .)com \
    --cc=sbeller@google$(echo .)com \
    --cc=sunshine@sunshineco$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox