Jeff King <> writes:

> On Tue, Nov 12, 2013 at 09:57:39AM -0800, Junio C Hamano wrote:
>> > With this patch "git-send-mail" ask a configurable number of questions to
>> > input the smtp password. Without this patch we have only one trial.
>> I wonder if Git::credential (or even the underlying lower level
>> credential_fill() in the helper API) should give hints to the caller
>> if calling it again may yield a different result.  An interactive
>> prompt may allow the user to mistype the password and then a later
>> call may return a correct one, but the .netrc helper will read from
>> the file and will return a fixed result, so there is no use calling
>> credential_fill() again.  And in the latter case, you do not want to
>> loop $askpasswordcount times.
> It would be pretty easy to add an "interactive=true" flag to the
> credential response (patch below). Credential readers are supposed to
> ignore elements that they don't understand. So storage helpers which are
> told "we got a password interactively" can choose to use that
> information if they want, but current implementations will fall back to
> ignoring it. Similarly, users of "git credential fill" can use it, but
> it won't hurt existing readers.

Yeah, it may be a sensible way forward.

>> I also have to wonder if this logic belongs to git-send-email.
>> Specifically, I wonder if we can place the looping logic in
>> Git::credential, so that other users of the library can take
>> advantage of it?
> A very early draft of the credential code added looping, but I cut it
> out (I think before it even made it to the list). I don't recall the
> exact reason, but it was probably a combination of:
>   1. It's awkward to do at the credential layer in C, because you need
>      input from the calling code on whether the credential worked or
>      not. The perl Git::credential can take a callback, though, which
>      means the credential code owns the outer loop, and it would be
>      pretty easy to just loop on trying.

I was wondering if it should go to Git::credential; I did not say it
might go to credential_fill() API, exactly for that "fill does not
know if that was accepted" reason.  We are in full agreement, I

> I guess "send-email" does not (always) fall under the same category
> because the user may have put work into a cover letter, or filling
> interactive fields. So I have no objection to adding it there, but I do
> agree we might as well put it in Git::credential.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to