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 <p...@peff.net> 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.kno...@gmail.com
> >     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

Reply via email to