On Fri, May 01, 2020 at 08:50:48AM -0700, Junio C Hamano wrote: > Carlo Marcelo Arenas Belón <carenas@xxxxxxxxx> writes: > > >> +of `sendemail.smtpPassCmd`), then a password is obtained using > >> +'git-credential'. > > > > this last part on git credential is just undocumented, since it is already > > doing so since 4d31a44a08 (git-send-email: use git credential to obtain > > password, 2013-02-12) > > > > and of course, assuming you use a credential helper that keeps the password > > encrypted you could use that instead of this new feature. > > Up to this point I understand your response. > > Documenting that "git send-email" can use "git credential" for its > password store, if it is not already documented, is of course a good > change. I agree completely. > But I am not sure why this is "a good alternative". Having more > choices that do not offer anything substantially different is a bad > thing. Is this "new mechanism" better in what way? Simpler to use? > Faster? Less error prone? Something else? Ditto. I don't think that an increased surface-area of possibilities to specify your password to 'git send-email' is useful. Put another way: why *not* use the in-built credential helper, which is already supported? Would having it documented eliminate some rationale for invoking a separate program? > Thanks. > > > having said that, this looks like a good alternative, but might need to > > make sure if die makes sense below or would be better to see if you can > > still get a password through git credential even if that fails. > > > > maybe the rule of what to do might even need some configuration itself. > > > > Carlo Thanks, Taylor
