Hi Duy, On Tue, 15 Mar 2016, Duy Nguyen wrote:
> On Thu, Mar 10, 2016 at 1:36 AM, David Turner <dtur...@twopensource.com> > wrote: > > Introduce a new config option, indexhelper.autorun, to automatically > > run git index-helper before starting up a builtin git command. This > > enables users to keep index-helper running without manual > > intervention. > > This could be a problem on Windows because "index-helper --detach" > does not work there. I have no idea how "daemons" are managed on > Windows and not sure if our design is still good when such a "daemon" > is added on Windows. So I'm pulling Johannes in for his opinions. > > Background for Johannes. We're adding "git index-helper" daemon (one > per repo) to cache the index in memory to speed up index load time > (and in future probably name-hash too, I think it's also more often > used on Windows because of case-insensitive fs). It also enables > watchman (on Windows) for faster refresh. This patch allows to start > the daemon automatically if it's not running. But I don't know it will > work ok on Windows. > > Assuming that "index-helper" service has to be installed and started > from system, there can only be one service running right? This clashes > with the per-repo daemon design... I think it can stilf work, if the > main service just spawns new process, one for each repo. But again I'm > not sure. If we want to run the process as a Windows service, you are correct, there really can only be one. Worse: it runs with admin privileges. But why not just keep it running as a detached process? We can run those on Windows, and if we're opening a named pipe whose name reveals the one-to-one mapping with the index in question, I think we are fine (read: we can detect whether the process is running already). We can even tell those processes to have a timeout, or to react to other system events. Please note that I am *very* interested in this feature (speeding up index operations). Ciao, Dscho -- 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
