Jeff King <peff@xxxxxxxx> writes: > So the ideal logic is: > > 1. look in netrc > > 2. If we have a username and no password, ask for password > > 3. Otherwise, try it and see if we get a 401. > > But we can't do that, because (1) and (3) happen atomically inside of > curl. > > The simplest thing is to just drop the behavior in (2), and let it drop > to a 401. The extra round trip probably isn't that big a deal. That is essentially what Stefan's fix is about. The cases we have "extra" roundtrip are: - when you have username@ in URL but no password is stored in .netrc; - when you have username@ in URL and no $HOME/.netrc file. and in such a case using URL without username@ in it as a workaround would save the roundtrip but forces you to type your username@ over and over again, which is _not_ a real workaround. A workaround for people who want ultimate convenience is to use .netrc to have both username:password, but that is at the cost of potentially reduced security. Having username@ in URL and typing password interactively, if it worked properly, would have been the best of both worlds. > The other option is to start parsing netrc ourselves, or do the extra > round trip if we detect ~/.netrc or something. But that last one is > getting pretty hackish. I tend to agree that we wouldn't want to parse netrc ourselves (that is what library support e.g. CURLOPT_NETRC is for). The latter is hackish but on the other hand it is a cheap, simple and useful hack. How would the upcoming keystore support fit in this picture, by the way? -- 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