Peff is completely right: the log showed host=smpt.gmail.com:587 as expected. Keychain confirms. Thanks! D. Ben Knoble P.S. Be sure to delete /tmp/credential.log afterwards to clean up your passwords. On Mon, Aug 12, 2019 at 6:18 PM Jeff King <peff@xxxxxxxx> wrote: > > On Mon, Aug 12, 2019 at 06:00:14PM -0400, D. Ben Knoble wrote: > > > I spent a frustrating hour today hoping to setup git-send-email with > > my gmail account. I've been able to confirm the following: > > > > 1. git credential works > > > > # git config credential.helper > > osxkeychain > > # git credential fill <<EOF > > protocol=smtp > > host=smtp.gmail.com > > EOF > > > > outputs the correct username and password for my gmail account. > > > > 2. I (believe) I setup gitconfig properly: > > > > # git config --get-regexp sendemail > > sendemail.smtpserver smtp.gmail.com > > sendemail.smtpuser ben.knoble@xxxxxxxxx > > sendemail.smtpencryption tls > > sendemail.smtpserverport 587 > > sendemail.multiedit true > > sendemail.annotate true > > > > The strange behavior I'm seeing is that git-send-email > > > > - prompted me via macOS for keychain access (expected). This happened > > twice in a row, during one command invocation. > > - prompted me at the terminal for my gmail password (shudders) > > - stopped prompting me for messages send after that (all within the 15 > > minutes of the first two) > > > > Can anyone confirm/explain what's going on? I've never tried to use > > git-credential or git-send-email before, so I'm new to those (but > > experienced in git). > > I don't think the saved password you're showing in step 1 is being > triggered, because Git will send "smtp.gmail.com:587" as the host field. > Try this: > > git \ > -c credential.helper='!exec >/tmp/credential.log 2>&1; cat; echo' \ > send-email ... > > which will log the helper request. It probably has: > > host=smtp.gmail.com:587 > > I don't remember the specifics of how osxkeychain works, but it probably > pulls the port out of that and passes it to the OS keychain code, which > then treats it as a separate service. > > So the rest of the behavior makes sense, then, I think: > > 1. macOS had to unlock your keychain to check for the entry > > 2. finding nothing, Git prompted you for the password > > 3. Git then wrote the password to keychain after it was used > successfully (maybe prompting another keychain password request? I > don't know how it works), after which it should work without a > password. > > -Peff