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

Re: Request for detailed documentation of git pack protocol

From
Jakub Narebski <jnareb@gmail.com>
Date
Jun 3, 2009, 22:04 UTC
Message-ID
<200906040004.18594.jnareb@gmail.com>
In-Reply-To
<20090603202429.GO3355@spearce.org>
On Wed, 3 Jun 2009, Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
Show 23 quoted lines
> > BTW. do "include-tag" capability MUST NOT (REQUIRED) be send if there
> > are not tags (tag objects?), or just SHOULD NOT (RECOMMENDED), or even
> > MAY NOT (OPTIONAL).  GitHub server doesn't send it if there are no 
> > tags...
> 
> Clients MAY always send include-tag, hardcoding it into a request.
> The decision for a client to request include-tag only has to do
> with the client's desires for tag data, whether or not a server
> had advertised objects in the refs/tags/* namespace.
> 
> Clients SHOULD NOT send include-tag if remote.name.tagopt was set
> to --no-tags, as the client doesn't want tag data.
> 
> Servers MUST accept include-tag without error or warning, even if the
> server does not understand or support the option.
> 
> Servers SHOULD pack the tags if their referrant is packed and the
> client has requested include-tag.
> 
> Clients MUST be prepared for the case where a server has ignored
> include-tag and has not actually sent tags in the pack.  In such
> cases the client SHOULD issue a subsequent fetch to acquire the
> tags that include-tag would have otherwise given the client.

So do I understand correctly that capabilities are governed by the following generic rules:

1. Server sends space separated list of capabilities it support. It
   MUST NOT send capabilities it *does not* support. It MAY NOT send
   "include-tag" if there are no tag objects (or is it SHOULD NOT?).
2. Client sends space separated list of capabilities it wants. It SHOULD
   (or perhaps it is MAY?) send subset of server capabilities, i.e do
   not send capabilities served does not advertise.
3. Server MUST ignore capabilities it does not understand. Server MUST
   NOT ignore capabilities (or SHOULD NOT only?) that client requested
   and server advertised.

I know that client MUST send only maximum of one of "side-band" and "side-band-64k", but how should server reacts if client sends both? Should it use "side-band-64k"?

-- 
Jakub Narebski
Poland
Previous: Shawn O. PearceNext: Shawn O. Pearce
Message 30 of 66 in “Request for detailed documentation of git pack protocol”
  1. Jakub NarebskiMay 12, 2009
  2. Shawn O. PearceMay 12, 2009
  3. Jakub NarebskiMay 14, 2009
  4. Shawn O. PearceMay 14, 2009
  5. Andreas EricssonMay 14, 2009
  6. Linus TorvaldsMay 15, 2009
  7. Clemens BuchacherMay 15, 2009
  8. Nicolas PitreMay 14, 2009
  9. Jakub NarebskiMay 14, 2009
  10. Scott ChaconMay 14, 2009
  11. Shawn O. PearceMay 14, 2009
  12. Jakub NarebskiMay 14, 2009
  13. A Large Angry SCMMay 15, 2009
  14. Ealdwulf WuffingaMay 15, 2009
  15. Jakub NarebskiJun 2, 2009
  16. Shawn O. PearceJun 2, 2009
  17. Jakub NarebskiJun 3, 2009
  18. Shawn O. PearceJun 3, 2009
  19. Junio C HamanoJun 3, 2009
  20. Shawn O. PearceJun 3, 2009
  21. Jakub NarebskiJun 3, 2009
  22. Shawn O. PearceJun 3, 2009
  23. Shawn O. PearceJun 3, 2009
  24. Jakub NarebskiJun 3, 2009
  25. Shawn O. PearceJun 3, 2009
  26. Jakub NarebskiJun 3, 2009
  27. Shawn O. PearceJun 3, 2009
  28. Jakub NarebskiJun 3, 2009
  29. Shawn O. PearceJun 3, 2009
  30. Jakub NarebskiJun 3, 2009
  31. Shawn O. PearceJun 3, 2009
  32. Junio C HamanoJun 3, 2009
  33. Jakub NarebskiJun 3, 2009
  34. Andreas EricssonJun 4, 2009
  35. Junio C HamanoJun 4, 2009
  36. Scott ChaconJun 6, 2009
  37. Junio C HamanoJun 6, 2009
  38. Jakub NarebskiJun 6, 2009
  39. Tony FinchJun 3, 2009
  40. Junio C HamanoJun 3, 2009
  41. Johannes SixtJun 3, 2009
  42. Robin H. JohnsonJun 3, 2009
  43. Jakub NarebskiJun 3, 2009
  44. Shawn O. PearceJun 3, 2009
  45. Tony FinchJun 3, 2009
  46. Jakub NarebskiJun 3, 2009
  47. Tony FinchJun 3, 2009
  48. Jakub NarebskiJun 4, 2009
  49. Tony FinchJun 4, 2009
  50. Shawn O. PearceJun 4, 2009
  51. Jakub NarebskiJun 3, 2009
  52. Shawn O. PearceJun 3, 2009
  53. Jakub NarebskiJun 4, 2009
  54. Shawn O. PearceJun 4, 2009
  55. Shawn O. PearceJun 5, 2009
  56. Jakub NarebskiJun 5, 2009
  57. Jakub NarebskiJun 5, 2009
  58. Comments pack protocol description in "Git Community Book" (second round)Jakub Narebski, Jun 6, 2009
  59. Scott ChaconJun 6, 2009
  60. Jakub NarebskiJun 7, 2009
  61. Shawn O. PearceJun 7, 2009
  62. Shawn O. PearceJun 7, 2009
  63. Jakub NarebskiJun 13, 2009
  64. Shawn O. PearceJun 7, 2009
  65. Jakub NarebskiJun 9, 2009
  66. Shawn O. PearceJun 9, 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.