@@ -255,12 +255,43 @@ A `fetch` request can take the following arguments:
255255 to its base by position in pack rather than by an oid. That is,
256256 they can read OBJ_OFS_DELTA (ake type 6) in a packfile.
257257
258+ shallow <oid>
259+ A client must notify the server of all commits for which it only
260+ has shallow copies (meaning that it doesn't have the parents of
261+ a commit) by supplying a 'shallow <oid>' line for each such
262+ object so that the server is aware of the limitations of the
263+ client's history. This is so that the server is aware that the
264+ client may not have all objects reachable from such commits.
265+
266+ deepen <depth>
267+ Requests that the fetch/clone should be shallow having a commit
268+ depth of <depth> relative to the remote side.
269+
270+ deepen-relative
271+ Requests that the semantics of the "deepen" command be changed
272+ to indicate that the depth requested is relative to the client's
273+ current shallow boundary, instead of relative to the requested
274+ commits.
275+
276+ deepen-since <timestamp>
277+ Requests that the shallow clone/fetch should be cut at a
278+ specific time, instead of depth. Internally it's equivalent to
279+ doing "git rev-list --max-age=<timestamp>". Cannot be used with
280+ "deepen".
281+
282+ deepen-not <rev>
283+ Requests that the shallow clone/fetch should be cut at a
284+ specific revision specified by '<rev>', instead of a depth.
285+ Internally it's equivalent of doing "git rev-list --not <rev>".
286+ Cannot be used with "deepen", but can be used with
287+ "deepen-since".
288+
258289The response of `fetch` is broken into a number of sections separated by
259290delimiter packets (0001), with each section beginning with its section
260291header.
261292
262293 output = *section
263- section = (acknowledgments | packfile)
294+ section = (acknowledgments | shallow-info | packfile)
264295 (flush-pkt | delim-pkt)
265296
266297 acknowledgments = PKT-LINE("acknowledgments" LF)
@@ -270,6 +301,11 @@ header.
270301 nak = PKT-LINE("NAK" LF)
271302 ack = PKT-LINE("ACK" SP obj-id LF)
272303
304+ shallow-info = PKT-LINE("shallow-info" LF)
305+ *PKT-LINE((shallow | unshallow) LF)
306+ shallow = "shallow" SP obj-id
307+ unshallow = "unshallow" SP obj-id
308+
273309 packfile = PKT-LINE("packfile" LF)
274310 *PKT-LINE(%x01-03 *%x00-ff)
275311
@@ -301,6 +337,35 @@ header.
301337 determined the objects it plans to send to the client and no
302338 further negotiation is needed.
303339
340+ shallow-info section
341+ If the client has requested a shallow fetch/clone, a shallow
342+ client requests a fetch or the server is shallow then the
343+ server's response may include a shallow-info section. The
344+ shallow-info section will be included if (due to one of the
345+ above conditions) the server needs to inform the client of any
346+ shallow boundaries or adjustments to the clients already
347+ existing shallow boundaries.
348+
349+ * Always begins with the section header "shallow-info"
350+
351+ * If a positive depth is requested, the server will compute the
352+ set of commits which are no deeper than the desired depth.
353+
354+ * The server sends a "shallow obj-id" line for each commit whose
355+ parents will not be sent in the following packfile.
356+
357+ * The server sends an "unshallow obj-id" line for each commit
358+ which the client has indicated is shallow, but is no longer
359+ shallow as a result of the fetch (due to its parents being
360+ sent in the following packfile).
361+
362+ * The server MUST NOT send any "unshallow" lines for anything
363+ which the client has not indicated was shallow as a part of
364+ its request.
365+
366+ * This section is only included if a packfile section is also
367+ included in the response.
368+
304369 packfile section
305370 * This section is only included if the client has sent 'want'
306371 lines in its request and either requested that no more
0 commit comments