Jeff King <peff@xxxxxxxx> writes: > But you snipped the later part of my message, which is that the "http" > in "http_proxy" does _not_ matter. It is about which destinations to > apply the proxy to, not how you talk to the proxy (and the latter is what > should matter for the credentials). Oh, yes, I am in violent agreement. The language the http clients (browsers etc) talk to the proxy may be part of HTTP specification, but it is definitely different from the "http" talked with the origin servers. >> > Not splitting "http" and "http-proxy" does have a slight confusion,... >> >> Ok, so how about this as a replacement patch for what I have had for the >> past few days? > > My other message argued "the http-proxy distinction might be important, > but probably isn't". But I didn't talk about "the http-proxy distinction > might break helpers". The stock helpers will be fine; they are totally > clueless about what the protocol means, and just treat it as a string to > be matched. But for something like osxkeychain, where it is converting > the protocol string into some OS-specific magic value, it does matter, > and http-proxy would cause it to exit in confusion. > > It looks like OS X defines a SOCKS type and an HTTPProxy type for its > keychain API. So in either case, it should probably be updated to handle > these new types. And I guess that argues for making the distinction, > since at least one helper does want to care about it. OK. Sounds like we are in agreement. Nelson, care to re-roll the series, with fixes discussed in this thread rolled into the second patch? -- 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