On Tue, Oct 27, 2015 at 10:52:52AM -0700, Junio C Hamano wrote:
> Jeff King <p...@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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
