Hi, On Thu, 26 Oct 2017, Ben Peart wrote: > On 10/26/2017 5:27 PM, Alex Vandiver wrote: > > On Thu, 26 Oct 2017, Ben Peart wrote: > > > On 10/25/2017 9:31 PM, Alex Vandiver wrote: > > > > diff --git a/fsmonitor.c b/fsmonitor.c > > > > index 7c1540c05..0d26ff34f 100644 > > > > --- a/fsmonitor.c > > > > +++ b/fsmonitor.c > > > > @@ -121,6 +121,7 @@ static int query_fsmonitor(int version, uint64_t > > > > last_update, struct strbuf *que > > > > argv[3] = NULL; > > > > cp.argv = argv; > > > > cp.use_shell = 1; > > > > + cp.dir = get_git_work_tree(); > > > > > > > > > > I'm not sure what would trigger this problem but I don't doubt that it is > > > possible. Better to be safe than sorry. This is a better/faster solution > > > than > > > you're previous patch. Thank you! > > > > See my response on the v1 of this series -- I'm curious how you're > > _not_ seeing it, actually. Can you not replicate just by running > > `git status` from differing parts of the working tree? > > - Alex > > > > I saw your response but actually can't replicate it locally. I've been > running with Watchman integration on all my repos for months and my "watchman > watch-list" command only shows the root of the various working directories - > no subdirectories. Indeed, I cannot replicate either. The thing is that "status" is marked with GIT_SETUP in git.c: https://github.com/git-for-windows/git/blob/v2.14.3.windows.1/git.c#L465 That means that the setup_git_directory() is run, which sets the current working directory to the top-level directory. So there is your explanation why neither Ben nor I saw this. And I agree with Ben that it is safer to do it the way you suggested, just in case that the call path comes from a Git command that was not marked with GIT_SETUP. Ciao, Johannes
