Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html