Hi guys! Any luck with fixing this issue? I would like to draw your attention to the fact that Git starting from version 2.3.1 is unusable with servers that support GSS-Negotiation (e.g. Microsoft TFS). Sorry, english is not my native language and probably I was not clear enough when described the problem at first time. So, let me try again. Algorithm of fetching data through HTTP(S) protocol is as follows: 1. Try to fetch data without any credentials. 2. If first step failed 2.1. Disable GSS-Negotiation algorithm (this is the side effect which is fixed by my patch). 2.2. Read credentials from config files. 2.3. If there is no credentials then ask user for it. 2.4. Go to step one, but now try to fetch data with found/provided credentials. As you can see there is no other way to connect to server with GSS-Negotiation auth than use URLs like "https://:@my-gss-git-server.com"; (because there is step zero where we are parsing URL which can contain credentials that we can use in step one). Maybe you could accept my patch, so users would use "credential.helper=store" to avoid using ":@" in remote URL? At least for now, while there is no good solution to this issue? It would be very helpful because now we have to have our own version of patched Git :( Thanks in advance. 2016-02-08 12:11 GMT+03:00 Dmitry Vilkov <dmitry.a.vilkov@xxxxxxxxx>: > 2016-02-06 0:52 GMT+03:00 Junio C Hamano <gitster@xxxxxxxxx>: >> "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: >> >>> On Fri, Feb 05, 2016 at 01:02:58PM -0800, Junio C Hamano wrote: >>>> Hmph, so documenting that <emptyname>:<emptypassword>@<repository> >>>> as a supported way might be an ugly-looking solution to the original >>>> problem. A less ugly-looking solution might be a boolean that can >>>> be set per URL (we already have urlmatch-config infrastructure to >>>> help us do so) to tell us to pass the empty credential to lubCurl, >>>> bypassing the step to ask the user for password that we do not use. >>>> >>>> The end-result of either of these solution would strictly be better >>>> than the patch we discussed in that the end user will not have to >>>> interact with the prompt at all, right? >>> >>> Yes, that's true. I'll try to come up with a patch this weekend that >>> implements that (maybe remote.forceAuth = true or somesuch). >> >> Thanks. >> >> I think the configuration should live inside http.* namespace, as >> there are already things like http[.<url>].sslCert and friends. >> >> I do not have a good suggestion on the name of the leaf-level >> variable. ForceAuth sounds as if you are forcing authentication >> even when the other side does not require it, though. > > That would be great! Definitely it will be much better solution than > patch I've proposed. -- 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