Documentation/technical/protocol-v2.txt: fix formatting
Asciidoctor versions v1.5.7 or later print the following warning while building the documentation: ASCIIDOC technical/protocol-v2.html asciidoctor: WARNING: protocol-v2.txt: line 38: unterminated listing block This highlights an issue (even with older Asciidoctor versions) where the 'Initial Client Request' header is not rendered as a header but in monospace. I'm not sure what exactly causes this issue and why it's an issue only with this particular header, but all headers in 'protocol-v2.txt' are written like this: Initial Client Request ------------------------ i.e. the header itself is indented by a space, and the "underline" is two characters longer than the header. Dropping that indentation and making the length of the underline match the length of the header apparently fixes this issue. While at it, adjust all other headers 'protocol-v2.txt' as well, to match the style we use everywhere else. The page rendered with AsciiDoc doesn't have this formatting issue. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
SZEDER Gábor committed
Mar 29, 2019 at 13:35 UTC
b373e4d29b7eb67a40efc038156a8edde7ae2972
1 file changed
+26
-26
Documentation/technical/protocol-v2.txt
+26
-26
@@ -1,5 +1,5 @@
1
- Git Wire Protocol, Version 2
2
-==============================
1
+Git Wire Protocol, Version 2
2
+============================
3
4
This document presents a specification for a version 2 of Git's wire
5
protocol. Protocol v2 will improve upon v1 in the following ways:
@@ -22,8 +22,8 @@ will be commands which a client can request be executed. Once a command
22
has completed, a client can reuse the connection and request that other
23
commands be executed.
24
25
- Packet-Line Framing
26
----------------------
25
+Packet-Line Framing
26
+-------------------
27
28
All communication is done using packet-line framing, just as in v1. See
29
`Documentation/technical/pack-protocol.txt` and
@@ -34,8 +34,8 @@ In protocol v2 these special packets will have the following semantics:
34
* '0000' Flush Packet (flush-pkt) - indicates the end of a message
35
* '0001' Delimiter Packet (delim-pkt) - separates sections of a message
36
37
- Initial Client Request
38
-------------------------
37
+Initial Client Request
38
+----------------------
39
40
In general a client can request to speak protocol v2 by sending
41
`version=2` through the respective side-channel for the transport being
@@ -43,22 +43,22 @@ used which inevitably sets `GIT_PROTOCOL`. More information can be
43
found in `pack-protocol.txt` and `http-protocol.txt`. In all cases the
44
response from the server is the capability advertisement.
45
46
- Git Transport
47
-~~~~~~~~~~~~~~~
46
+Git Transport
47
+~~~~~~~~~~~~~
48
49
When using the git:// transport, you can request to use protocol v2 by
50
sending "version=2" as an extra parameter:
51
52
003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0
53
54
- SSH and File Transport
55
-~~~~~~~~~~~~~~~~~~~~~~~~
54
+SSH and File Transport
55
+~~~~~~~~~~~~~~~~~~~~~~
56
57
When using either the ssh:// or file:// transport, the GIT_PROTOCOL
58
environment variable must be set explicitly to include "version=2".
59
60
- HTTP Transport
61
-~~~~~~~~~~~~~~~~
60
+HTTP Transport
61
+~~~~~~~~~~~~~~
62
63
When using the http:// or https:// transport a client makes a "smart"
64
info/refs request as described in `http-protocol.txt` and requests that
@@ -79,8 +79,8 @@ A v2 server would reply:
79
Subsequent requests are then made directly to the service
80
`$GIT_URL/git-upload-pack`. (This works the same for git-receive-pack).
81
82
- Capability Advertisement
83
---------------------------
82
+Capability Advertisement
83
+------------------------
84
85
A server which decides to communicate (based on a request from a client)
86
using protocol version 2, notifies the client by sending a version string
@@ -101,8 +101,8 @@ to be executed by the client.
101
key = 1*(ALPHA | DIGIT | "-_")
102
value = 1*(ALPHA | DIGIT | " -_.,?\/{}[]()<>!@#$%^&*+=:;")
103
104
- Command Request
105
------------------
104
+Command Request
105
+---------------
106
107
After receiving the capability advertisement, a client can then issue a
108
request to select the command it wants with any particular capabilities
@@ -137,8 +137,8 @@ command be executed or can terminate the connection. A client may
137
optionally send an empty request consisting of just a flush-pkt to
138
indicate that no more requests will be made.
139
140
- Capabilities
141
---------------
140
+Capabilities
141
+------------
142
143
There are two different types of capabilities: normal capabilities,
144
which can be used to to convey information or alter the behavior of a
@@ -153,8 +153,8 @@ management on the server side in order to function correctly. This
153
permits simple round-robin load-balancing on the server side, without
154
needing to worry about state management.
155
156
- agent
157
-~~~~~~~
156
+agent
157
+~~~~~
158
159
The server can advertise the `agent` capability with a value `X` (in the
160
form `agent=X`) to notify the client that the server is running version
@@ -168,8 +168,8 @@ printable ASCII characters except space (i.e., the byte range 32 < x <
168
and debugging purposes, and MUST NOT be used to programmatically assume
169
the presence or absence of particular features.
170
171
- ls-refs
172
-~~~~~~~~~
171
+ls-refs
172
+~~~~~~~
173
174
`ls-refs` is the command used to request a reference advertisement in v2.
175
Unlike the current reference advertisement, ls-refs takes in arguments
@@ -199,8 +199,8 @@ The output of ls-refs is as follows:
199
symref = "symref-target:" symref-target
200
peeled = "peeled:" obj-id
201
202
- fetch
203
-~~~~~~~
202
+fetch
203
+~~~~~
204
205
`fetch` is the command used to fetch a packfile in v2. It can be looked
206
at as a modified version of the v1 fetch where the ref-advertisement is
@@ -444,8 +444,8 @@ header.
444
2 - progress messages
445
3 - fatal error message just before stream aborts
446
447
- server-option
448
-~~~~~~~~~~~~~~~
447
+server-option
448
+~~~~~~~~~~~~~
449
450
If advertised, indicates that any number of server specific options can be
451
included in a request. This is done by sending each option as a