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

Re: [RFC/PATCH 0/3] protocol v2

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 2, 2015, 03:10 UTC
Message-ID
<xmqqioekf629.fsf@gitster.dls.corp.google.com>
In-Reply-To
<alpine.DEB.2.02.1503011707040.12474@nftneq.ynat.uz>
David Lang <david@lang.hm> writes:
Show 5 quoted lines
> how would these approaches be affected by a client that is pulling
> from different remotes into one local repository? For example, pulling
> from the main kernel repo and from the -stable repo.
>
> David Lang
As I said in $gmane/264000, which the above came from:
    Note that the above would work if and only if we accept that it
    is OK to send objects between the remote tracking branches the
    fetcher has (i.e. the objects it last fetched from the server)
    and the current tips of branches the server has, without
    optimizing by taking into account that some commits in that set
    may have already been obtained by the fetcher from a
    third-party.

The scheme tries go gain by reducing the ref advertisement cost by sacrificing the optimization opportunity when you fetch from updated Linus's tree after having fetched from a recent next tree, the latter of which may have contained a lot of objects that went to the Linus's tree since you fetched from Linus's the last time. The current protocol, by negotiating what you have (including the objects you obtained from sideways via 'next') with the Linus's tree, allows the server to compute a minimum packfile customized just for you. By trading that off with "everybody that follow this repository will get the same set of packfiles in sequence trickled into his repository" model, it would instead allow the server to prepare these packfiles thousands of clients that follow Linus's tree will want only once.

The client-server pair may want to have a negociation mechanism (e.g. "I may have many objects I fetched from sideways, give me minimum pack that is customized for me by spending cycles---I am willing to wait until you finish computing it" vs "I am just following along and not doing anything fancy, just give me the same thing as everybody else") to select what optimization they want to use.

Previous: David LangNext: Philip Oakley
Message 77 of 80 in “protocol v2”
  1. 0/3 protocol v2Stefan Beller, Feb 24, 2015
  2. 1/3 Document protocol capabilities extensionStefan Beller, Feb 24, 2015
  3. 2/3 receive-pack: add advertisement of different protocol optionsStefan Beller, Feb 24, 2015
  4. 3/3 receive-pack: enable protocol v2Stefan Beller, Feb 24, 2015
  5. Duy NguyenFeb 24, 2015
  6. Stefan BellerFeb 24, 2015
  7. Junio C HamanoFeb 24, 2015
  8. Stefan BellerFeb 24, 2015
  9. Duy NguyenFeb 25, 2015
  10. Junio C HamanoFeb 25, 2015
  11. Stefan BellerFeb 26, 2015
  12. Duy NguyenFeb 26, 2015
  13. Stefan BellerFeb 26, 2015
  14. Junio C HamanoFeb 26, 2015
  15. Stefan BellerFeb 27, 2015
  16. Stefan BellerFeb 27, 2015
  17. Junio C HamanoFeb 27, 2015
  18. Stefan BellerFeb 27, 2015
  19. Junio C HamanoFeb 28, 2015
  20. Stefan BellerFeb 28, 2015
  21. 0/5 protocol v2 for upload-packStefan Beller, Feb 28, 2015
  22. 1/5 upload-pack: only accept capabilities on the first "want" lineStefan Beller, Feb 28, 2015
  23. 2/5 upload-pack: support out of band client capability requestsStefan Beller, Feb 28, 2015
  24. Kyle J. McKayFeb 28, 2015
  25. Duy NguyenFeb 28, 2015
  26. Kyle J. McKayFeb 28, 2015
  27. Duy NguyenMar 1, 2015
  28. Duy NguyenFeb 28, 2015
  29. 3/5 connect.c: connect to a remote service with some flagsStefan Beller, Feb 28, 2015
  30. Torsten BögershausenFeb 28, 2015
  31. Junio C HamanoMar 1, 2015
  32. 4/5 daemon.c: accept extra service argumentsStefan Beller, Feb 28, 2015
  33. Junio C HamanoMar 1, 2015
  34. 5/5 WIP/Document the http protocol changeStefan Beller, Feb 28, 2015
  35. Duy NguyenFeb 28, 2015
  36. Johannes SixtMar 1, 2015
  37. Junio C HamanoMar 2, 2015
  38. Junio C HamanoMar 2, 2015
  39. Duy NguyenMar 2, 2015
  40. Duy NguyenMar 2, 2015
  41. Duy NguyenMar 3, 2015
  42. Junio C HamanoMar 3, 2015
  43. Junio C HamanoMar 3, 2015
  44. Duy NguyenMar 4, 2015
  45. Shawn PearceMar 4, 2015
  46. Duy NguyenMar 4, 2015
  47. Shawn PearceMar 4, 2015
  48. Stefan BellerMar 5, 2015
  49. Stefan BellerMar 5, 2015
  50. Stefan BellerMar 24, 2015
  51. Junio C HamanoMar 24, 2015
  52. protocol upload-pack-v2Stefan Beller, Mar 6, 2015
  53. Stefan BellerMar 6, 2015
  54. Duy NguyenMar 6, 2015
  55. Duy NguyenMar 7, 2015
  56. Junio C HamanoMar 7, 2015
  57. Stefan BellerMar 7, 2015
  58. Duy NguyenMar 7, 2015
  59. Junio C HamanoMar 8, 2015
  60. Junio C HamanoMar 31, 2015
  61. Duy NguyenApr 2, 2015
  62. Junio C HamanoApr 2, 2015
  63. Martin FickApr 2, 2015
  64. Junio C HamanoApr 2, 2015
  65. Stefan BellerApr 2, 2015
  66. Stefan BellerApr 2, 2015
  67. Duy NguyenMar 10, 2015
  68. Kyle J. McKayMar 10, 2015
  69. Duy NguyenFeb 28, 2015
  70. Junio C HamanoFeb 28, 2015
  71. Junio C HamanoMar 1, 2015
  72. Duy NguyenMar 1, 2015
  73. Stefan BellerMar 1, 2015
  74. David LangMar 2, 2015
  75. Junio C HamanoMar 1, 2015
  76. David LangMar 2, 2015
  77. Junio C HamanoMar 2, 2015
  78. Philip OakleyMar 1, 2015
  79. Duy NguyenMar 2, 2015
  80. Stefan BellerFeb 27, 2015

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.