On Mon, 12 Oct 2009, Shawn O. Pearce wrote: > Some network protocols (e.g. native git://) are able to fetch more > than one ref at a time and reduce the overall transfer cost by > combining the requests into a single exchange. Instead of feeding > each fetch request one at a time to the helper, feed all of them > at once so the helper can decide whether or not it should batch them. > > Because 'fetch' was already released in 1.6.5 we introduce the new > fetch-multiple capability/command to signal that the helper wants > to use batch oriented approach to fetching refs. In 1.6.5, there's no way to call a helper other than git-remote-curl, and no way to call git-remote-curl unless 1.6.5 was built with it. So I think the protocol is not set in stone quite yet. It's documentated for being an API, and it's supposed to be that, but it's not quite there in this version. I think it should be generally a good idea to have a start signal and an end signal for a block of fetches (and, with the foreign stuff, it would be useful to have transport-helper tell the helper process when it was done making requests, so the helper process could tell the gfi process to exit and stop consuming the helper process's output). At worst, if the helper doesn't care, it can just ignore this information. -Daniel *This .sig left intentionally blank* -- 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