From: Eric Sunshine Date: Mon, 22 Dec 2014 22:52:48 GMT Subject: Re: [PATCH 1/7] receive-pack.c: add protocol support to negotiate atomic-push Message-ID: In-Reply-To: <1419017941-7090-2-git-send-email-sbeller@google.com> On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller wrote: > From: Ronnie Sahlberg > > 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. > > Signed-off-by: Ronnie Sahlberg > Signed-off-by: Stefan Beller > --- > 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 > @@ -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 Not itself worth a re-send, but if you re-send for some other reason... "one atomic" still smacks of redundancy; "an atomic" sounds better. > +updated or none. > + > allow-tip-sha1-in-want > ----------------------