On Fri, Jul 15, 2016 at 2:18 PM, Jeff King <[email protected]> wrote:
> Some features, like the index-helper, aren't quite so easy. One reason
> is that its data needs to persist as a cache between multiple git
> invocations. In general, I think it would be nice to solve that by
> communicating via on-disk files, rather than a running daemon (just
> because it has fewer moving parts). But that's only half of it for
> index-helper. It needs to monitor inotify while git isn't running at
> all; so it really _does_ need some kind of long-running daemon.
This *may* have changed in the recent versions of the series, but I'm
fairly sure and for what it's worth to this discussion, that's not
what the index-helper does. It's there to keep the index file in
memory instead of reading it from disk.
It can *also* if you "git update-index --watchman" spawn a watchman
daemon in the background, which is the thing that'll be doing the
inotify calls and needs to stay persistent, the index-helper then
communicates with the watchman daemon "what changed since X?" to
compute a new index when requested.
I.e. if you:
$ git config indexhelper.autorun true
$ git update-index --watchman
You'll end up with both:
$ ps ax|grep -e index-helper -e watchman|grep -v grep
61958 ? Ss 0:00 git-index-helper --detach --autorun
62813 ? Sl 0:04 watchman get-sockname
So for the purposes of your example the index-helper is one of those
things that doesn't "need" to persist as a demon, only the third party
watchman daemon does, but the index-helper speeds up reading the index
since it keeps it alive in memory.
All or some of the above may be wrong, Nguyen/David, any comments?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
