On 4/26/2021 11:47 AM, Derrick Stolee wrote:
> On 4/1/21 11:40 AM, Jeff Hostetler via GitGitGadget wrote:
>> From: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx>
> ...
>> + /* Prepare to (recursively) watch the <worktree-root> directory. */
>> + strbuf_init(&state.path_worktree_watch, 0);
>> + strbuf_addstr(&state.path_worktree_watch, absolute_path(get_git_work_tree()));
>> + state.nr_paths_watching = 1;
>
> Yes, let's watch the working directory.
>
>> + /*
>> + * If ".git" is not a directory, then <gitdir> is not inside the
>> + * cone of <worktree-root>, so set up a second watch for it.
>> + */
>> + strbuf_init(&state.path_gitdir_watch, 0);
>> + strbuf_addbuf(&state.path_gitdir_watch, &state.path_worktree_watch);
>> + strbuf_addstr(&state.path_gitdir_watch, "/.git");
>> + if (!is_directory(state.path_gitdir_watch.buf)) {
>> + strbuf_reset(&state.path_gitdir_watch);
>> + strbuf_addstr(&state.path_gitdir_watch, absolute_path(get_git_dir()));
>> + state.nr_paths_watching = 2;
>> + }
>
> But why watch the .git directory, especially for a worktree (or
> submodule I guess)? What benefit do we get from events within the
> .git directory? I'm expecting any event within the .git directory
> should be silently ignored.
I see in a following patch that we place a cookie file within the
.git directory. I'm reminded that this is done for a reason: other
filesystem watchers can get into a loop if we place the cookie
file outside of the .git directory. The classic example is VS Code
running 'git status' in a loop because Watchman writes a cookie
into the root of the working directory.
Thanks,
-Stolee
