git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC PATCH v2 05/16] Add multi_ack_2 capability to fetch-pack/upload-pack

From
Jakub Narebski <jnareb@gmail.com>
Date
Oct 13, 2009, 21:35 UTC
Message-ID
<m3ocobf067.fsf@localhost.localdomain>
In-Reply-To
<1255400715-10508-6-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> When multi_ack_2 is enabled the ACK continue messages returned by the
> remote upload-pack are broken out to describe the different states
> within the peer.  This permits the client to better understand the
> server's in-memory state.

Errr... can't you find better name than multi_ack_2? Perhaps multi_ack_detailed or something...

> 
> The fetch-pack/upload-pack protocol now looks like:
[...]
Show 36 quoted lines
> ACK %s continue
> -----------------------------------
>   * multi_ack only:
> 
>     Sent in response to "have".
> 
>     The remote side wants the client to consider this object as
>     common, and immediately stop transmitting additional "have"
>     lines for objects that are reachable from it.  The reason
>     the client should stop is not given, but is one of the two
>     cases below available under multi_ack_2.
> 
> ACK %s common
> -----------------------------------
>   * multi_ack_2 only:
> 
>     Sent in response to "have".  Both sides have this object.
>     Like with "ACK %s continue" above the client should stop
>     sending have lines reachable for objects from the argument.
> 
> ACK %s ready
> -----------------------------------
>   * multi_ack_2 only:
> 
>     Sent in response to "have".
> 
>     The client should stop transmitting objects which are reachable
>     from the argument, and send "done" soon to get the objects.
> 
>     If the remote side has the specified object, it should
>     first send an "ACK %s common" message prior to sending
>     "ACK %s ready".
> 
>     Clients may still submit additional "have" lines if there are
>     more side branches for the client to explore that might be added
>     to the common set and reduce the number of objects to transfer.
-- 
Jakub Narebski
Poland
ShadeHawk on #git
Previous: Shawn O. PearceNext: Shawn O. Pearce
Message 9 of 38 in “Return of smart HTTP”
  1. 00/16 Return of smart HTTPShawn O. Pearce, Oct 13, 2009
  2. 01/16 pkt-line: Add strbuf based functionsShawn O. Pearce, Oct 13, 2009
  3. Johannes SixtOct 13, 2009
  4. Shawn O. PearceOct 13, 2009
  5. 02/16 pkt-line: Make packet_read_line easier to debugShawn O. Pearce, Oct 13, 2009
  6. 03/16 fetch-pack: Use a strbuf to compose the want listShawn O. Pearce, Oct 13, 2009
  7. 04/16 Move "get_ack()" back to fetch-packShawn O. Pearce, Oct 13, 2009
  8. 05/16 Add multi_ack_2 capability to fetch-pack/upload-packShawn O. Pearce, Oct 13, 2009
  9. Jakub NarebskiOct 13, 2009
  10. Shawn O. PearceOct 13, 2009
  11. 06/16 remote-curl: Refactor walker initializationShawn O. Pearce, Oct 13, 2009
  12. 07/16 remote-helpers: Fetch more than one ref in a batchShawn O. Pearce, Oct 13, 2009
  13. Daniel BarkalowOct 13, 2009
  14. Shawn O. PearceOct 13, 2009
  15. 08/16 remote-helpers: Support custom transport optionsShawn O. Pearce, Oct 13, 2009
  16. Daniel BarkalowOct 13, 2009
  17. Shawn O. PearceOct 13, 2009
  18. Daniel BarkalowOct 13, 2009
  19. Shawn O. PearceOct 13, 2009
  20. Daniel BarkalowOct 13, 2009
  21. Shawn O. PearceOct 13, 2009
  22. 09/16 Move WebDAV HTTP push under remote-curlShawn O. Pearce, Oct 13, 2009
  23. Mike HommeyOct 13, 2009
  24. Johannes SchindelinOct 13, 2009
  25. 10/16 Git-aware CGI to provide dumb HTTP transportShawn O. Pearce, Oct 13, 2009
  26. Johannes SixtOct 13, 2009
  27. 11/16 Add one shot RPC options to upload-pack, receive-packShawn O. Pearce, Oct 13, 2009
  28. 12/16 Smart fetch and push over HTTP: server sideShawn O. Pearce, Oct 13, 2009
  29. Johannes SixtOct 13, 2009
  30. Shawn O. PearceOct 13, 2009
  31. 13/16 Discover refs via smart HTTP server when availableShawn O. Pearce, Oct 13, 2009
  32. 14/16 Smart push over HTTP: client sideShawn O. Pearce, Oct 13, 2009
  33. Felipe ContrerasOct 13, 2009
  34. 15/16 Smart fetch over HTTP: client sideShawn O. Pearce, Oct 13, 2009
  35. 16/16 Smart HTTP fetch: gzip requestsShawn O. Pearce, Oct 13, 2009
  36. Junio C HamanoOct 13, 2009
  37. eduard stefanOct 13, 2009
  38. Junio C HamanoOct 13, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.