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

From: Jeff King <peff@peff.net>
Date: Oct 27, 2015, 18:47 UTC
Message-ID: <20151027184702.GB12717@sigill.intra.peff.net>
In-Reply-To: <xmqqoafkci6j.fsf@gitster.mtv.corp.google.com>

On Tue, Oct 27, 2015 at 10:52:52AM -0700, Junio C Hamano wrote:

Show 19 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > But these days, people often have several simultaneous sessions open.
> > They may have multiple ssh sessions to a single machine, or they may
> > have a bunch of terminal windows open, each of which has a login shell
> > and will send HUP to its children when it exits. In that case, you have
> > a meta-session surrounding those individual terminal sessions, and you
> > probably do want to keep the cache going as long as the meta session[1].
> > ...
> > [1] Of course we have no idea when that meta-session is closed. But if
> >     you have a script that runs on X logout, for instance, you could put
> >     "git credential-cache exit" in it.
> 
> Yes.  Probably the right way forward is to make it a non-issue by
> teaching users how to control the lifetime of the "daemon" process,
> and wean them off relying on "it is auto-spawned if you forgot to
> start", as that convenience of auto-spawning is associated with
> "...but how it is auto-shutdown really depends on many things in
> your specific environment", which is the issue.

I dunno. I think the auto-spawn is really what makes it usable; you can drop it in with "git config credential.helper config" and forget about it. Anything more fancy requires touching your login/startup files. Certainly I'm not opposed to people setting it up outside of the auto-spawn, but I wouldn't want that feature to go away.

AFAICT, it works pretty well out of the box for most setups (where terminals do _not_ send SIGHUP; so we auto-start, and then it holds the credential until the timer expires).

I am a little surprised that credential-cache gets wide use. I would think most people would prefer to use a system-specific secure-storage helper. I don't know what the state of the art is for that on Linux[1], but we seem to have only gnome-keyring in contrib/.

-Peff

[1] I use Linux, but I do not use any of the common desktop
    environments. However, I have my own personal read-only key program
    that speaks the helper protocol.