1
- Git Wire Protocol, Version 2
2
- ==============================
1
+ Git Wire Protocol, Version 2
2
+ ============================
3
3
4
4
This document presents a specification for a version 2 of Git's wire
5
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
22
has completed, a client can reuse the connection and request that other
23
23
commands be executed.
24
24
25
- Packet-Line Framing
26
- ---------------------
25
+ Packet-Line Framing
26
+ -------------------
27
27
28
28
All communication is done using packet-line framing, just as in v1. See
29
29
`Documentation/technical/pack-protocol.txt` and
@@ -34,31 +34,31 @@ In protocol v2 these special packets will have the following semantics:
34
34
* '0000' Flush Packet (flush-pkt) - indicates the end of a message
35
35
* '0001' Delimiter Packet (delim-pkt) - separates sections of a message
36
36
37
- Initial Client Request
38
- ------------------------
37
+ Initial Client Request
38
+ ----------------------
39
39
40
40
In general a client can request to speak protocol v2 by sending
41
41
`version=2` through the respective side-channel for the transport being
42
42
used which inevitably sets `GIT_PROTOCOL`. More information can be
43
43
found in `pack-protocol.txt` and `http-protocol.txt`. In all cases the
44
44
response from the server is the capability advertisement.
45
45
46
- Git Transport
47
- ~~~~~~~~~~~~~~~
46
+ Git Transport
47
+ ~~~~~~~~~~~~~
48
48
49
49
When using the git:// transport, you can request to use protocol v2 by
50
50
sending "version=2" as an extra parameter:
51
51
52
52
003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0
53
53
54
- SSH and File Transport
55
- ~~~~~~~~~~~~~~~~~~~~~~~~
54
+ SSH and File Transport
55
+ ~~~~~~~~~~~~~~~~~~~~~~
56
56
57
57
When using either the ssh:// or file:// transport, the GIT_PROTOCOL
58
58
environment variable must be set explicitly to include "version=2".
59
59
60
- HTTP Transport
61
- ~~~~~~~~~~~~~~~~
60
+ HTTP Transport
61
+ ~~~~~~~~~~~~~~
62
62
63
63
When using the http:// or https:// transport a client makes a "smart"
64
64
info/refs request as described in `http-protocol.txt` and requests that
@@ -79,8 +79,8 @@ A v2 server would reply:
79
79
Subsequent requests are then made directly to the service
80
80
`$GIT_URL/git-upload-pack`. (This works the same for git-receive-pack).
81
81
82
- Capability Advertisement
83
- --------------------------
82
+ Capability Advertisement
83
+ ------------------------
84
84
85
85
A server which decides to communicate (based on a request from a client)
86
86
using protocol version 2, notifies the client by sending a version string
@@ -101,8 +101,8 @@ to be executed by the client.
101
101
key = 1*(ALPHA | DIGIT | "-_")
102
102
value = 1*(ALPHA | DIGIT | " -_.,?\/{}[]()<>!@#$%^&*+=:;")
103
103
104
- Command Request
105
- -----------------
104
+ Command Request
105
+ ---------------
106
106
107
107
After receiving the capability advertisement, a client can then issue a
108
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
137
optionally send an empty request consisting of just a flush-pkt to
138
138
indicate that no more requests will be made.
139
139
140
- Capabilities
141
- --------------
140
+ Capabilities
141
+ ------------
142
142
143
143
There are two different types of capabilities: normal capabilities,
144
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
153
permits simple round-robin load-balancing on the server side, without
154
154
needing to worry about state management.
155
155
156
- agent
157
- ~~~~~~~
156
+ agent
157
+ ~~~~~
158
158
159
159
The server can advertise the `agent` capability with a value `X` (in the
160
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
168
and debugging purposes, and MUST NOT be used to programmatically assume
169
169
the presence or absence of particular features.
170
170
171
- ls-refs
172
- ~~~~~~~~~
171
+ ls-refs
172
+ ~~~~~~~
173
173
174
174
`ls-refs` is the command used to request a reference advertisement in v2.
175
175
Unlike the current reference advertisement, ls-refs takes in arguments
@@ -199,8 +199,8 @@ The output of ls-refs is as follows:
199
199
symref = "symref-target:" symref-target
200
200
peeled = "peeled:" obj-id
201
201
202
- fetch
203
- ~~~~~~~
202
+ fetch
203
+ ~~~~~
204
204
205
205
`fetch` is the command used to fetch a packfile in v2. It can be looked
206
206
at as a modified version of the v1 fetch where the ref-advertisement is
@@ -444,8 +444,8 @@ header.
444
444
2 - progress messages
445
445
3 - fatal error message just before stream aborts
446
446
447
- server-option
448
- ~~~~~~~~~~~~~~~
447
+ server-option
448
+ ~~~~~~~~~~~~~
449
449
450
450
If advertised, indicates that any number of server specific options can be
451
451
included in a request. This is done by sending each option as a
0 commit comments