On Wed, Oct 05, 2011 at 01:55:36PM -0400, Jeff King wrote: > On Tue, Oct 04, 2011 at 08:49:55PM +0200, Michael J Gruber wrote: > > > We seem to mean something different: > > > > git config --get remote.bitbucket.pushurl > > https://grubix@xxxxxxxxxxxxx/grubix/git.git > > SSH_ASKPASS= git push -n bitbucket > > Username for 'bitbucket.org': > > > > I mean that git should not need to ask for the username here. > > No, we are in agreement about the intended behavior. I think you are > seeing a bug. What version of git produced it? > > With my http-auth series, I get: > > $ git push https://github.com/peff/git.git > Username for 'github.com': > > $ git push https://peff@xxxxxxxxxx/peff/git.git > Password for 'github.com': > > Using v1.7.7 produces similar results. Hrm. I do get this, with the same version of git: $ git config remote.foo.url https://github.com/peff/git.git $ git push foo Username for 'github.com': $ git config remote.foo.url https://peff@xxxxxxxxxx/peff/git.git $ git push foo Password for 'github.com': So far so good. Now how about this: $ git config remote.foo.url https://github.com/peff/git.git $ git config remote.foo.pushurl https://peff@xxxxxxxxxx/peff/git.git $ git push foo Username for 'github.com': So I think the problem is with pushurl, not with the auth code. Oddly, though, running GIT_TRACE reveals: $ GIT_TRACE=1 git push foo trace: built-in: git 'push' 'foo' trace: run_command: 'git-remote-https' 'foo' 'https://peff@xxxxxxxxxx/peff/git.git' which is the right URL. So it's almost as if we are throwing away the passed URL in favor of the configuration, and then looking up the configuration wrong. I'm about to go get on a plane, so I don't have more time to look at it now, but I suspect it's something simple and stupid. -Peff -- 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