Jeff King <peff@xxxxxxxx> 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 think. > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html