On Fri, Dec 19, 2014 at 2:38 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > From: Ronnie Sahlberg <sahlberg@xxxxxxxxxx> > > 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 <sahlberg@xxxxxxxxxx> > Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx> > --- > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html