Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

[Jeff King <peff@peff.net>]

On Thu, Oct 29, 2015 at 09:20:01PM -0400, Noam Postavsky wrote:

> On Thu, Oct 29, 2015 at 8:50 PM, Jeff King <peff@peff.net> wrote:
> > workaround (the real inelegance is that you are assuming that "foo"
> > needs run in the first place).
> 
> Well, we currently check the output from "git config
> credential.helpers" to determine what's needed, so the inelegance here
> is that we reimplement git's checking of this option.

Right. And not only is that hard to get right (I doubt, for example, you
support the arbitrary "!" shell expressions that git does), but it's
impossible to know for sure that will be needed, because you cannot know
all possible helpers (I might even have a helper that is a shell snippet
that calls credential-cache).

As a workaround, I don't think looking for just "cache" is unreasonable.
But it is not a very robust solution. :)

> > I'm still not sure how the pre-helper would work. What git command kicks
> > off the pre-helper command? Wouldn't it also be subject to the SIGHUP
> > problem?
> 
> Ah, maybe the missing piece I forgot to mention is that we could make
> our pre/1st-helper be an emacsclient command, which would tell Emacs
> to startup the daemon. So the daemon would be a subprocess of Emacs,
> not "git push", thereby avoiding the SIGHUP. In our current workaround
> we startup the daemon (if it's not running) before git commands that
> we think are going to run credential helpers (i.e. "push", "pull",
> "fetch"), hence my thought that it would be nicer if we only did that
> before git is *actually* going to run the helpers.

I don't think even git knows it will need a helper until it is actually
ready to call one (e.g., it may depend on getting an HTTP 401 from the
server).

I am leaning more towards ignoring SIGHUP (configurably) being the only
really sane path forward. Do you want to try your hand at a patch?

-Peff