On Thu, Dec 04, 2014 at 01:33:53PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > On Thu, Dec 04, 2014 at 10:24:09AM -0800, Junio C Hamano wrote: > > > >> I wish this covered a lot more than just this part from an > >> end-user's point of view, but this is definitely one of the most > >> important code paths the mechanism should cover. > > > > Which parts do you mean? Stuff like "git add -i"? > > No, more like "tag -s" that eventually leads to somebody prompting > for the passphrase to unlock your GPG key---and from an end user's > point of view, that somebody is Git. Ah, yeah, I definitely agree that GIT_TERMINAL_PROMPT should work there, too. > Of course, from _our_ point of view, that somebody is not us. We do > not have direct control, certainly from this codepath. Right, but in theory we can provoke gpg to do what we want when we spawn it. However, having had zero luck in convincing it to stop asking me for a passphrase recently in another thread, I do not know what magic command line option is required. :( I think it would be OK to merge the git handling of GIT_TERMINAL_PROMPT (i.e., the patch I sent), and somebody who runs into the issue with gpg and can figure out how to tame it can scratch their own itch later. I hate leaving things half-implemented or inconsistent, but I also don't know how to make gpg do what we want. And doing a partial solution seems better to me than holding the credential.c half hostage. -Peff -- 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