On Wed, Mar 4, 2015 at 12:13 AM, Junio C Hamano <gits...@pobox.com> wrote: > My recollection is that the consensus from the last time we > discussed protocol revamping was to list one capability per packet > so that packet length limit does not matter, but you may want to > check with the list archive yourself.
I couldn't find that consensus mail, but this one [1] is good enough evidence that we can hit packet length limit in capability line easily. With an escape hatch to allow maximum packet length up to uint_max, I think we'll be fine for a long time even if we don't send one cap per pkt-line. So I'm trying to see if we really want to go with one cap per pkt-line.. Pros: - better memory management, current pkt-line static buffer is probably fine - a capability can contain spaces after '=' Cons: - some refactoring needed to hide away differences between v1 and v2 Looks like one cap per pkt-line is winning.. [1] http://thread.gmane.org/gmane.comp.version-control.git/237929 -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
