summaryrefslogtreecommitdiff
path: root/Documentation/technical/protocol-capabilities.txt
AgeCommit message (Collapse)AuthorFilesLines
2013-11-25send-pack: don't send a thin pack to a server which doesn't support itLibravatar Carlos Martín Nieto1-8/+23
Up to now git has assumed that all servers are able to fix thin packs. This is however not always the case. Document the 'no-thin' capability and prevent send-pack from generating a thin pack if the server advertises it. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-26document 'allow-tip-sha1-in-want' capabilityLibravatar Nguyễn Thái Ngọc Duy1-0/+7
See 390eb36 (upload-pack: optionally allow fetching from the tips of hidden refs - 2013-01-28) for more information. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-24document 'quiet' receive-pack capabilityLibravatar Jeff King1-1/+11
This was added in c207e34 (fix push --quiet: add 'quiet' capability to receive-pack, 2012-01-08) but never documented. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-24document 'agent' protocol capabilityLibravatar Jeff King1-1/+16
This was added in ff5effd (include agent identifier in capability string, 2012-08-03), but neither the syntax nor the semantics were ever documented outside of the commit message. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-24docs: note that receive-pack knows side-band-64k capabilityLibravatar Jeff King1-2/+2
The protocol-capabilities documentation notes that any capabilities not explicitly mentioned for receive-pack work only for upload-pack. Receive-pack has advertised and understood side-band-64k since 38a81b4 (receive-pack: Wrap status reports inside side-band-64k, 2010-02-05), but we do not mention it explicitly. Let's do so. Note that receive-pack does not understand side-band, which was obsolete by that point. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-24docs: fix 'report-status' protocol capability thinkoLibravatar Jeff King1-1/+1
The report-status capability is understood by receive-pack, not upload-pack. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-09Documentation: Spelling fix in protocol-capabilities.txtLibravatar Fredrik Skolmli1-1/+1
Signed-off-by: Fredrik Skolmli <fredrik@frsk.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-31Fix typos in technical documentation.Libravatar Ralf Wildenhues1-2/+2
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-13Update packfile transfer protocol documentationLibravatar Scott Chacon1-0/+187
The current technical documentation for the packfile protocol is both sparse and incorrect. This documents the fetch-pack/upload-pack and send-pack/ receive-pack protocols much more fully. Add documentation from Shawn's upcoming http-protocol docs that is shared by the packfile protocol. protocol-common.txt describes ABNF notation amendments, refname rules and the packet line format. Add documentation on the various capabilities supported by the upload-pack and receive-pack protocols. protocol-capabilities.txt describes multi-ack, thin-pack, side-band[-64k], shallow, no-progress, include-tag, ofs-delta, delete-refs and report-status. Signed-off-by: Scott Chacon <schacon@gmail.com> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>