On Wed, Nov 3, 2021 at 6:10 AM Jeff King wrote:
> Hmm, that's the right output, I think. Even though it's wrapped in
> single-quotes I think that's just how run_command shows it.
Why does this have no quotes:
run-command.c:666 trace: run_command: git-remote-https origin
https://github.com/89z/googleplay
and this have quotes:
run-command.c:666 trace: run_command: 'git credential-store get'
If youre saying that both commands ran unquoted, then I believe you. But
hopefully you'll agree that even if nothing is wrong with the code that runs the
commands, that the output is confusing at best, and misleading at worst.
> So I'm quite confused about exactly what's failing and why. At this point I'd
> probably try running it under strace to see what's actually happening at the
> syscall level. I don't think you said what OS you're on; if it's Linux,
With all due respect, I am not going to do that. I am on Windows. I used "git
credential-store" years ago, and it worked fine. Then at some point, I
changed to
using Netrc, as it worked with both Git, and also cURL. I recently discovered
that the Python Requests [1] package will use Netrc as well, and that even if
you explicitly provide an Authorization header, Requests just go ahead and
ignores that, and uses Netrc instead. This was causing failed responses, and the
maintainers don't seem interested in fixing it, with the advice being
"just don't
use Netrc". So I decided to go back to "git credential-store", only to discover
that it doesn't work anymore.
Hopefully you won't fault me for just wanting something that works, so I am just
going to use my AskPass program [2] that I wrote in response to this situation.
Ironically, "git push" is actually faster now than it was with Netrc, so I guess
that's a win. Thanks for the responses.
1. https://docs.python-requests.org
2. http://public-inbox.org/git/CAP8dQmvguqPXy6Rg_RkuFmf4+LPh79HM_EBM+Wi9dYn3N+vrcQ@xxxxxxxxxxxxxx
