From: Jeff Hostetler Date: Tue, 11 May 2021 19:24:09 GMT Subject: Re: [PATCH] fsmonitor: only enable it in non-bare repositories Message-ID: In-Reply-To: <87k0oex1yi.fsf@evledraar.gmail.com> On 5/3/21 1:56 PM, Ævar Arnfjörð Bjarmason wrote: > On Mon, May 03 2021, Jeff Hostetler wrote: > >> On 5/3/21 9:58 AM, Ævar Arnfjörð Bjarmason wrote: >>> On Thu, Apr 29 2021, Johannes Schindelin via GitGitGadget wrote: >>> >>>> From: Johannes Schindelin >>>> >>>> The entire point of the FSMonitor is to monitor the worktree changes in >>>> a more efficient manner than `lstat()`ing all worktree files every time >>>> we refresh the index. >>>> >>>> But if there is no worktree, FSMonitor has nothing to monitor. >>>> >>>> So let's ignore if an FSMonitor is configured (e.g. in `~/.gitconfig`) >>>> and we're running in a repository without worktree. >>>> >>>> Signed-off-by: Johannes Schindelin >>>> --- >> ... >>>> >>>> base-commit: 14d50074ff19e68e7a8d718b22d138882087bbc9 >>> This is surely a correct fix for now, but wouldn't it in the future >>> also >>> be useful to run it in bare repositories e.g. to be able cache lookups >>> for non-existing loose objects? >>> >> >> No, the FSMonitor feature only expects data for paths within the >> working directory. (And is independent of whether the FS change >> data is provided by my fsmonitor--daemon or provided by a hook-based >> provider, such as Watchman.) The FSMonitor feature uses that data to >> shortcut scans of the working directory. > > Indeed, hence "in the future". I'm not suggesting that it'll do anything > useful by watching anything in the .git directory now, but that it might > be an interesting thing to explore. > >> There is no interaction with the contents of the .git/objects >> directory and I'm not sure how that would work. > > We'd watch .git/objects and .git/objects/{aa..ff}, then when about to > check for a loose object we'd avoid hitting the FS. > > I don't know how useful that is post-61c7711cfea (sha1-file: use loose > object cache for quick existence check, 2018-11-12), but e.g. on NFS > this sort of thing still mattered. I had a "bigger hammer" approach with > [1] that ran (and still does, I believe) on a big corporate > installation. > > More generally, if you strace .git access during repo operations you'll > find we're doing all sorts of existence checks etc. all the time. Loose > objects, refs, seeing what packs there are (better with the MIDX, but do > we still fall back?) etc. If we had up-to-date inotify/fsmonitor info we > could ask the daemon about it. > > 1. https://lore.kernel.org/git/20181028225023.26427-5-avarab@gmail.com/ > Interesting. That's certainly something to look into later. I know there is code in the object lookup code to rescan/reload the packfiles or loose objects (under the assumption that another process just created a new packfile (and after our process loaded the packed-git list)). Such a daemon might be helpful to improve something like that. But I can't think about any of that right now. I'd like to finish the current fsmonitor--daemon patch series and let it settle down before starting to think about an orthogonal use case such as this. Thanks Jeff