| 1 | gitprotocol-capabilities(5) |
| 2 | =========================== |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | gitprotocol-capabilities - Protocol v0 and v1 capabilities |
| 7 | |
| 8 | SYNOPSIS |
| 9 | -------- |
| 10 | [verse] |
| 11 | <over-the-wire-protocol> |
| 12 | |
| 13 | DESCRIPTION |
| 14 | ----------- |
| 15 | |
| 16 | NOTE: this document describes capabilities for versions 0 and 1 of the pack |
| 17 | protocol. For version 2, please refer to the linkgit:gitprotocol-v2[5] |
| 18 | doc. |
| 19 | |
| 20 | Servers SHOULD support all capabilities defined in this document. |
| 21 | |
| 22 | On the very first line of the initial server response of either |
| 23 | receive-pack and upload-pack the first reference is followed by |
| 24 | a NUL byte and then a list of space delimited server capabilities. |
| 25 | These allow the server to declare what it can and cannot support |
| 26 | to the client. |
| 27 | |
| 28 | Client will then send a space separated list of capabilities it wants |
| 29 | to be in effect. The client MUST NOT ask for capabilities the server |
| 30 | did not say it supports. |
| 31 | |
| 32 | Server MUST diagnose and abort if capabilities it does not understand |
| 33 | were sent. Server MUST NOT ignore capabilities that client requested |
| 34 | and server advertised. As a consequence of these rules, server MUST |
| 35 | NOT advertise capabilities it does not understand. |
| 36 | |
| 37 | The 'atomic', 'report-status', 'report-status-v2', 'delete-refs', |
| 38 | 'no-ref-delta', 'quiet', and 'push-cert' capabilities are sent and |
| 39 | recognized by the receive-pack (push to server) process. |
| 40 | |
| 41 | The 'ofs-delta' and 'side-band-64k' capabilities are sent and recognized |
| 42 | by both upload-pack and receive-pack protocols. The 'agent' and 'session-id' |
| 43 | capabilities may optionally be sent in both protocols. |
| 44 | |
| 45 | All other capabilities are only recognized by the upload-pack (fetch |
| 46 | from server) process. |
| 47 | |
| 48 | multi_ack |
| 49 | --------- |
| 50 | |
| 51 | The 'multi_ack' capability allows the server to return "ACK obj-id |
| 52 | continue" as soon as it finds a commit that it can use as a common |
| 53 | base, between the client's wants and the client's have set. |
| 54 | |
| 55 | By sending this early, the server can potentially head off the client |
| 56 | from walking any further down that particular branch of the client's |
| 57 | repository history. The client may still need to walk down other |
| 58 | branches, sending have lines for those, until the server has a |
| 59 | complete cut across the DAG, or the client has said "done". |
| 60 | |
| 61 | Without multi_ack, a client sends have lines in --date-order until |
| 62 | the server has found a common base. That means the client will send |
| 63 | have lines that are already known by the server to be common, because |
| 64 | they overlap in time with another branch on which the server hasn't found |
| 65 | a common base yet. |
| 66 | |
| 67 | For example suppose the client has commits in caps that the server |
| 68 | doesn't and the server has commits in lower case that the client |
| 69 | doesn't, as in the following diagram: |
| 70 | |
| 71 | +---- u ---------------------- x |
| 72 | / +----- y |
| 73 | / / |
| 74 | a -- b -- c -- d -- E -- F |
| 75 | \ |
| 76 | +--- Q -- R -- S |
| 77 | |
| 78 | If the client wants x,y and starts out by saying have F,S, the server |
| 79 | doesn't know what F,S is. Eventually the client says "have d" and |
| 80 | the server sends "ACK d continue" to let the client know to stop |
| 81 | walking down that line (so don't send c-b-a), but it's not done yet, |
| 82 | it needs a base for x. The client keeps going with S-R-Q, until a |
| 83 | gets reached, at which point the server has a clear base and it all |
| 84 | ends. |
| 85 | |
| 86 | Without multi_ack the client would have sent that c-b-a chain anyway, |
| 87 | interleaved with S-R-Q. |
| 88 | |
| 89 | multi_ack_detailed |
| 90 | ------------------ |
| 91 | This is an extension of multi_ack that permits the client to better |
| 92 | understand the server's in-memory state. See linkgit:gitprotocol-pack[5], |
| 93 | section "Packfile Negotiation" for more information. |
| 94 | |
| 95 | no-done |
| 96 | ------- |
| 97 | This capability should only be used with the smart HTTP protocol. If |
| 98 | multi_ack_detailed and no-done are both present, then the sender is |
| 99 | free to immediately send a pack following its first "ACK obj-id ready" |
| 100 | message. |
| 101 | |
| 102 | Without no-done in the smart HTTP protocol, the server session would |
| 103 | end and the client has to make another trip to send "done" before |
| 104 | the server can send the pack. no-done removes the last round and |
| 105 | thus slightly reduces latency. |
| 106 | |
| 107 | thin-pack |
| 108 | --------- |
| 109 | |
| 110 | A thin pack is one with deltas which reference base objects not |
| 111 | contained within the pack (but are known to exist at the receiving |
| 112 | end). This can reduce the network traffic significantly, but it |
| 113 | requires the receiving end to know how to "thicken" these packs by |
| 114 | adding the missing bases to the pack. |
| 115 | |
| 116 | The upload-pack server advertises 'thin-pack' when it can generate |
| 117 | and send a thin pack. A client requests the 'thin-pack' capability |
| 118 | when it understands how to "thicken" it, notifying the server that |
| 119 | it can receive such a pack. A client MUST NOT request the |
| 120 | 'thin-pack' capability if it cannot turn a thin pack into a |
| 121 | self-contained pack. |
| 122 | |
| 123 | Receive-pack, on the other hand, is assumed by default to be able to |
| 124 | handle thin packs, but can ask the client not to use the feature by |
| 125 | advertising the 'no-thin' capability. A client MUST NOT send a thin |
| 126 | pack if the server advertises the 'no-thin' capability. |
| 127 | |
| 128 | The reasons for this asymmetry are historical. The receive-pack |
| 129 | program did not exist until after the invention of thin packs, so |
| 130 | historically the reference implementation of receive-pack always |
| 131 | understood thin packs. Adding 'no-thin' later allowed receive-pack |
| 132 | to disable the feature in a backwards-compatible manner. |
| 133 | |
| 134 | |
| 135 | side-band, side-band-64k |
| 136 | ------------------------ |
| 137 | |
| 138 | This capability means that the server can send, and the client can understand, multiplexed |
| 139 | progress reports and error info interleaved with the packfile itself. |
| 140 | |
| 141 | These two options are mutually exclusive. A modern client always |
| 142 | favors 'side-band-64k'. |
| 143 | |
| 144 | Either mode indicates that the packfile data will be streamed broken |
| 145 | up into packets of up to either 1000 bytes in the case of 'side_band', |
| 146 | or 65520 bytes in the case of 'side_band_64k'. Each packet is made up |
| 147 | of a leading 4-byte pkt-line length of how much data is in the packet, |
| 148 | followed by a 1-byte stream code, followed by the actual data. |
| 149 | |
| 150 | The stream code can be one of: |
| 151 | |
| 152 | 1 - pack data |
| 153 | 2 - progress messages |
| 154 | 3 - fatal error message just before stream aborts |
| 155 | |
| 156 | The "side-band-64k" capability came about as a way for newer clients |
| 157 | that can handle much larger packets to request packets that are |
| 158 | actually crammed nearly full, while maintaining backward compatibility |
| 159 | for the older clients. |
| 160 | |
| 161 | Further, with side-band and its up to 1000-byte messages, it's actually |
| 162 | 999 bytes of payload and 1 byte for the stream code. With side-band-64k, |
| 163 | same deal, you have up to 65519 bytes of data and 1 byte for the stream |
| 164 | code. |
| 165 | |
| 166 | The client MUST send only one of "side-band" and "side- |
| 167 | band-64k". The server MUST diagnose it as an error if client requests |
| 168 | both. |
| 169 | |
| 170 | ofs-delta |
| 171 | --------- |
| 172 | |
| 173 | The server can send, and the client can understand, PACKv2 with delta referring to |
| 174 | its base by position in pack rather than by an obj-id. That is, they can |
| 175 | send/read OBJ_OFS_DELTA (aka type 6) in a packfile. |
| 176 | |
| 177 | no-ref-delta |
| 178 | ------------ |
| 179 | |
| 180 | The receive-pack server can request, and the client can send, PACKv2 |
| 181 | without deltas referring to their bases by an obj-id. That is, the |
| 182 | client MUST NOT send OBJ_REF_DELTA (aka type 7) in a packfile when the |
| 183 | server advertises this capability. |
| 184 | |
| 185 | This does not imply that the server understands OBJ_OFS_DELTA entries; |
| 186 | that is negotiated separately with the 'ofs-delta' capability. |
| 187 | |
| 188 | agent |
| 189 | ----- |
| 190 | |
| 191 | The server may optionally send a capability of the form `agent=X` to |
| 192 | notify the client that the server is running version `X`. The client may |
| 193 | optionally return its own agent string by responding with an `agent=Y` |
| 194 | capability (but it MUST NOT do so if the server did not mention the |
| 195 | agent capability). The `X` and `Y` strings may contain any printable |
| 196 | ASCII characters except space (i.e., the byte range 32 < x < 127), and |
| 197 | are typically of the form "package/version" (e.g., "git/1.8.3.1"). The |
| 198 | agent strings are purely informative for statistics and debugging |
| 199 | purposes, and MUST NOT be used to programmatically assume the presence |
| 200 | or absence of particular features. |
| 201 | |
| 202 | object-format |
| 203 | ------------- |
| 204 | |
| 205 | This capability, which takes a hash algorithm as an argument, indicates |
| 206 | that the server supports the given hash algorithms. It may be sent |
| 207 | multiple times; if so, the first one given is the one used in the ref |
| 208 | advertisement. |
| 209 | |
| 210 | When provided by the client, this indicates that it intends to use the |
| 211 | given hash algorithm to communicate. The algorithm provided must be one |
| 212 | that the server supports. |
| 213 | |
| 214 | If this capability is not provided, it is assumed that the only |
| 215 | supported algorithm is SHA-1. |
| 216 | |
| 217 | symref |
| 218 | ------ |
| 219 | |
| 220 | This parameterized capability is used to inform the receiver which symbolic ref |
| 221 | points to which ref; for example, "symref=HEAD:refs/heads/master" tells the |
| 222 | receiver that HEAD points to master. This capability can be repeated to |
| 223 | represent multiple symrefs. |
| 224 | |
| 225 | Servers SHOULD include this capability for the HEAD symref if it is one of the |
| 226 | refs being sent. |
| 227 | |
| 228 | Clients MAY use the parameters from this capability to select the proper initial |
| 229 | branch when cloning a repository. |
| 230 | |
| 231 | shallow |
| 232 | ------- |
| 233 | |
| 234 | This capability adds "deepen", "shallow" and "unshallow" commands to |
| 235 | the fetch-pack/upload-pack protocol so clients can request shallow |
| 236 | clones. |
| 237 | |
| 238 | deepen-since |
| 239 | ------------ |
| 240 | |
| 241 | This capability adds "deepen-since" command to fetch-pack/upload-pack |
| 242 | protocol so the client can request shallow clones that are cut at a |
| 243 | specific time, instead of depth. Internally it's equivalent of doing |
| 244 | "rev-list --max-age=<timestamp>" on the server side. "deepen-since" |
| 245 | cannot be used with "deepen". |
| 246 | |
| 247 | deepen-not |
| 248 | ---------- |
| 249 | |
| 250 | This capability adds "deepen-not" command to fetch-pack/upload-pack |
| 251 | protocol so the client can request shallow clones that are cut at a |
| 252 | specific revision, instead of depth. Internally it's equivalent of |
| 253 | doing "rev-list --not <rev>" on the server side. "deepen-not" |
| 254 | cannot be used with "deepen", but can be used with "deepen-since". |
| 255 | |
| 256 | deepen-relative |
| 257 | --------------- |
| 258 | |
| 259 | If this capability is requested by the client, the semantics of |
| 260 | "deepen" command is changed. The "depth" argument is the depth from |
| 261 | the current shallow boundary, instead of the depth from remote refs. |
| 262 | |
| 263 | no-progress |
| 264 | ----------- |
| 265 | |
| 266 | The client was started with "git clone -q" or something similar, and doesn't |
| 267 | want that side band 2. Basically the client just says "I do not |
| 268 | wish to receive stream 2 on sideband, so do not send it to me, and if |
| 269 | you did, I will drop it on the floor anyway". However, the sideband |
| 270 | channel 3 is still used for error responses. |
| 271 | |
| 272 | include-tag |
| 273 | ----------- |
| 274 | |
| 275 | The 'include-tag' capability is about sending annotated tags if we are |
| 276 | sending objects they point to. If we pack an object to the client, and |
| 277 | a tag object points exactly at that object, we pack the tag object too. |
| 278 | In general this allows a client to get all new annotated tags when it |
| 279 | fetches a branch, in a single network connection. |
| 280 | |
| 281 | Clients MAY always send include-tag, hardcoding it into a request when |
| 282 | the server advertises this capability. The decision for a client to |
| 283 | request include-tag only has to do with the client's desires for tag |
| 284 | data, whether or not a server had advertised objects in the |
| 285 | refs/tags/* namespace. |
| 286 | |
| 287 | Servers MUST pack the tags if their referent is packed and the client |
| 288 | has requested include-tags. |
| 289 | |
| 290 | Clients MUST be prepared for the case where a server has ignored |
| 291 | include-tag and has not actually sent tags in the pack. In such |
| 292 | cases the client SHOULD issue a subsequent fetch to acquire the tags |
| 293 | that include-tag would have otherwise given the client. |
| 294 | |
| 295 | The server SHOULD send include-tag, if it supports it, regardless |
| 296 | of whether or not there are tags available. |
| 297 | |
| 298 | report-status |
| 299 | ------------- |
| 300 | |
| 301 | The receive-pack process can receive a 'report-status' capability, |
| 302 | which tells it that the client wants a report of what happened after |
| 303 | a packfile upload and reference update. If the pushing client requests |
| 304 | this capability, after unpacking and updating references the server |
| 305 | will respond with whether the packfile unpacked successfully and if |
| 306 | each reference was updated successfully. If any of those were not |
| 307 | successful, it will send back an error message. See linkgit:gitprotocol-pack[5] |
| 308 | for example messages. |
| 309 | |
| 310 | report-status-v2 |
| 311 | ---------------- |
| 312 | |
| 313 | Capability 'report-status-v2' extends capability 'report-status' by |
| 314 | adding new "option" directives in order to support reference rewritten by |
| 315 | the "proc-receive" hook. The "proc-receive" hook may handle a command |
| 316 | for a pseudo-reference which may create or update a reference with |
| 317 | different name, new-oid, and old-oid. While the capability |
| 318 | 'report-status' cannot report for such case. See linkgit:gitprotocol-pack[5] |
| 319 | for details. |
| 320 | |
| 321 | delete-refs |
| 322 | ----------- |
| 323 | |
| 324 | If the server sends back the 'delete-refs' capability, it means that |
| 325 | it is capable of accepting a zero-id value as the target |
| 326 | value of a reference update. It is not sent back by the client, it |
| 327 | simply informs the client that it can be sent zero-id values |
| 328 | to delete references. |
| 329 | |
| 330 | quiet |
| 331 | ----- |
| 332 | |
| 333 | If the receive-pack server advertises the 'quiet' capability, it is |
| 334 | capable of silencing human-readable progress output which otherwise may |
| 335 | be shown when processing the received pack. A send-pack client should |
| 336 | respond with the 'quiet' capability to suppress server-side progress |
| 337 | reporting if the local progress reporting is also being suppressed |
| 338 | (e.g., via `push -q`, or if stderr does not go to a tty). |
| 339 | |
| 340 | atomic |
| 341 | ------ |
| 342 | |
| 343 | If the server sends the 'atomic' capability it is capable of accepting |
| 344 | atomic pushes. If the pushing client requests this capability, the server |
| 345 | will update the refs in one atomic transaction. Either all refs are |
| 346 | updated or none. |
| 347 | |
| 348 | push-options |
| 349 | ------------ |
| 350 | |
| 351 | If the server sends the 'push-options' capability it is able to accept |
| 352 | push options after the update commands have been sent, but before the |
| 353 | packfile is streamed. If the pushing client requests this capability, |
| 354 | the server will pass the options to the pre- and post- receive hooks |
| 355 | that process this push request. |
| 356 | |
| 357 | allow-tip-sha1-in-want |
| 358 | ---------------------- |
| 359 | |
| 360 | If the upload-pack server advertises this capability, fetch-pack may |
| 361 | send "want" lines with object names that exist at the server but are not |
| 362 | advertised by upload-pack. For historical reasons, the name of this |
| 363 | capability contains "sha1". Object names are always given using the |
| 364 | object format negotiated through the 'object-format' capability. |
| 365 | |
| 366 | allow-reachable-sha1-in-want |
| 367 | ---------------------------- |
| 368 | |
| 369 | If the upload-pack server advertises this capability, fetch-pack may |
| 370 | send "want" lines with object names that exist at the server but are not |
| 371 | advertised by upload-pack. For historical reasons, the name of this |
| 372 | capability contains "sha1". Object names are always given using the |
| 373 | object format negotiated through the 'object-format' capability. |
| 374 | |
| 375 | push-cert=<nonce> |
| 376 | ----------------- |
| 377 | |
| 378 | The receive-pack server that advertises this capability is willing |
| 379 | to accept a signed push certificate, and asks the <nonce> to be |
| 380 | included in the push certificate. A send-pack client MUST NOT |
| 381 | send a push-cert packet unless the receive-pack server advertises |
| 382 | this capability. |
| 383 | |
| 384 | filter |
| 385 | ------ |
| 386 | |
| 387 | If the upload-pack server advertises the 'filter' capability, |
| 388 | fetch-pack may send "filter" commands to request a partial clone |
| 389 | or partial fetch and request that the server omit various objects |
| 390 | from the packfile. |
| 391 | |
| 392 | session-id=<session-id> |
| 393 | ----------------------- |
| 394 | |
| 395 | The server may advertise a session ID that can be used to identify this process |
| 396 | across multiple requests. The client may advertise its own session ID back to |
| 397 | the server as well. |
| 398 | |
| 399 | Session IDs should be unique to a given process. They must fit within a |
| 400 | packet-line, and must not contain non-printable or whitespace characters. The |
| 401 | current implementation uses trace2 session IDs (see |
| 402 | link:technical/api-trace2.html[api-trace2] for details), but this may change |
| 403 | and users of the session ID should not rely on this fact. |
| 404 | |
| 405 | GIT |
| 406 | --- |
| 407 | Part of the linkgit:git[1] suite |