Re: [PATCH] send-email: fix docs regarding storing password with git credential

2018-04-07 Thread Michał Nazarewicz
2018-04-04 22:14 GMT+01:00 Jeff King :
> On the other hand, I'm not sure why we need to pre-seed here. Wouldn't
> it be sufficient to just issue a "git send-email", which would then
> prompt for the password? And then you'd input your generated token,
> which would get saved via the approve mechanism?

Yeah, this is precisely what I’ve figured as well.  As long as the credentials
helper is configured git-send-email will approve the password and it’ll be
stored then. New patch sent.


Re: [PATCH] send-email: fix docs regarding storing password with git credential

2018-04-04 Thread Jeff King
On Tue, Apr 03, 2018 at 12:23:48AM +0100, Michal Nazarewicz wrote:

> First of all, ‘git credential fill’ does not store credentials
> but is used to *read* them.  The command which adds credentials
> to the helper’s store is ‘git credential approve’.

Yep, makes sense (I wish we had just called these consistently "get",
"store", and "erase" as they are in the git<->helper interface).

> Second of all, git-send-email will include port number in host
> parameter when getting the password so it has to be set when
> storing the password as well.
> 
> Apply the two above to fix the Gmail example in git-send-email
> documentation.

Makes sense. This is an interesting counter-example to my earlier "well,
it usually works out in the long run" statement. Because usually you're
relying on some part of Git to issue the "fill" and the "approve", so
whatever it uses, it will be the same. But here we're trying to
pre-seed, so we have to match what the tool will do.

On the other hand, I'm not sure why we need to pre-seed here. Wouldn't
it be sufficient to just issue a "git send-email", which would then
prompt for the password? And then you'd input your generated token,
which would get saved via the approve mechanism?

-Peff