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

Re: Is anyone working on a next-gen Git protocol?

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 7, 2012, 22:31 UTC
Message-ID
<7va9vxq5gp.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CACBZZX6b+3P8M+z+X13k9Pq3tvVUfs_k1=foQVreX8K801=efQ@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 17 quoted lines
> On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>>
>>> I'm creating a system where a lot of remotes constantly fetch from a
>>> central repository for deployment purposes, but I've noticed that even
>>> with a remote.$name.fetch configuration to only get certain refs a
>>> "git fetch" will still call git-upload pack which will provide a list
>>> of all references.
>>
>> It has been observed that the sender has to advertise megabytes of
>> refs because it has to speak first before knowing what the receiver
>> wants, even when the receiver is interested in getting updates from
>> only one of them, or worse yet, when the receiver is only trying to
>> peek the ref it is interested has been updated.
>
> Has anyone started working on a next-gen Git protocol as a result of
> this discussion?

I and Shawn helped privately somebody from Gerrit circle, where the initial ref advertisement is a huge problem (primarily because they add tons of refs to one commit that eventually goes to their integration branch), to coming up with a problem description and proposal document to kick-start a discussion some time ago, but not much has happened since. Unless I hear from them soonish, I'll send a cleaned-up version of the draft before I leave for my vacation.

The gist of it is that the current protocol cannot be upgraded in place because "who speaks first" is not something you can update with capability, so we would need upload-pack-v2 that lets the fetching side speak first.

"What is spoken in the first message" is a separate issue, and one of the things it can address is to allow the ends to reduce the amount of ref advertisement that ends up not getting used in the end, but once we allow the fetcher to speak first, we have much wider possibilities.

Previous: Jeff KingNext: Junio C Hamano
Message 4 of 12 in “Is anyone working on a next-gen Git protocol?”
  1. Ævar Arnfjörð BjarmasonOct 7, 2012
  2. Ilari LiusvaaraOct 7, 2012
  3. Jeff KingOct 7, 2012
  4. Junio C HamanoOct 7, 2012
  5. Junio C HamanoOct 22, 2012
  6. Andreas EricssonOct 8, 2012
  7. Junio C HamanoOct 8, 2012
  8. Steffen ProhaskaOct 10, 2012
  9. Junio C HamanoOct 10, 2012
  10. Philip OakleyOct 10, 2012
  11. Nguyen Thai Ngoc DuyOct 11, 2012
  12. Shawn PearceOct 11, 2012

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.