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
