"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > Ilari Liusvaara <ilari.liusvaara@xxxxxxxxxxx> wrote: >> >> For instance, to support new types of authentication for smart transports >> without patching client git binaries (SSH has lots of failure modes that >> are quite nasty to debug) or abusing GIT_PROXY (yuck). > > So the bulk of this series is about making a proxy for git:// > easier to tie into git? > > Forgive me if I sound stupid, but for gits:// shouldn't that just > be a matter of git_connect() forking a git-remote-gits process > linked against openssl? Or, maybe it just runs `openssl s_client`? > > Why go through all of this effort of making a really generic proxy > protocol system when the long-term plan is to just ship native > gits:// support as part of git-core? I didn't know what the long-term plan was to be honest, but after skimming the series, I think your response is a good summary. It is somewhat unfortunate that a few changes I liked (e.g. the "debug" bit), even though it was somewhat painful to read them due to coding style differences, were not at the beginning of the series but instead buried after changes that are much bigger and controversial (e.g. [6/8]). -- 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