On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller <sbel...@google.com> wrote: > From: Ronnie Sahlberg <sahlb...@google.com> > > 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 <sahlb...@google.com> > Signed-off-by: Stefan Beller <sbel...@google.com> > --- > 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 > ---------------------- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
