On Wed, Feb 25, 2015 at 10:04 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Duy Nguyen <pclouds@xxxxxxxxx> writes: > >> On Wed, Feb 25, 2015 at 6:37 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: >>> I can understand, that we maybe want to just provide one generic >>> "version 2" of the protocol which is an allrounder not doing bad in >>> all of these aspects, but I can see usecases of having the desire to >>> replace the wire protocol by your own implementation. To do so >>> we could try to offer an API which makes implementing a new >>> protocol somewhat easy. The current state of affairs is not providing >>> this flexibility. >> >> I think we are quite flexible after initial ref advertisement. > > Yes, that is exactly where my "I am not convinced" comes from. > We are not. (not really at least). We can tune some parameters or change the behavior slightly, but we cannot fix core assumptions made when creating v2 protocol. This you can see when when talking about v1 as well: we cannot fix any wrongdoings of v1 now by adding another capability. So from my point of view we don't waste resources when having an advertisement of possible protocols instead of a boolean flag indicating v2 is supported. There is really not much overhead in coding nor bytes exchanged on the wire, so why not accept stuff that comes for free (nearly) ? I mean how do we know all the core assumptions made for v2 hold in the future? We don't. That's why I'd propose a plain and easy exchange at first stating the version to talk. Anyway what is the cost of a round trip time compared to the bytes on the wire? Usually the cost of bytes on the wire correlate with the latency anyway. (think mobile metered compared to corporate setting with low latency). That's why I'd rather optimize for used bandwidth than round trip times, but that may be just my personal perception of the internet. That's why I'd propose different protocols. Thanks, Stefan -- 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