On Tue, Dec 02, 2014 at 05:29:50PM -0800, Jonathan Nieder wrote: > Jeff King wrote: > > On Tue, Dec 02, 2014 at 04:59:53PM -0800, Jonathan Nieder wrote: > > >> As long as you have no credential helpers configured, your GIT_ASKPASS > >> based approach should work fine. > > > > Yeah, it's fine (as is GIT_ASKPASS=true). You could also provide a > > credential helper that gives you an empty username and password. But in > > both cases, I think that git will then feed the empty password to the > > server again, resulting in an extra useless round-trip. You probably > > instead want to say "stop now, git, there is nothing else to be done". > > > > We could teach the credential-helper code to do that (e.g., a helper > > returns "stop=true" and we respect that). But I think you can do it > > reasonably well today by making the input process fail. > > How can my scripts defend against a credential helper that I didn't > set up that e.g. pops up a GUI window to ask for a password?
Maybe I am misunderstanding the original situation, but I did not think that was the problem. I thought the situation was one where the environment was controlled, but Git still would not do what was wanted (if you did have such a renegade helper, setting GIT_ASKPASS certainly would not help, as it is the fallback). But to answer your question: you can't currently. I would be happy to have a config syntax that means "reset this multi-value config option list to nothing", but it does not yet exist. It would be useful for more than just credential-helper config. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
