On Fri, Jul 1, 2022 at 3:15 PM Eric D <eric.decosta@xxxxxxxxx> wrote: > > One more possibility: > > Leave the check, but make it a warning if there are still concerns > about running fsmonitor against network file systems. Maybe also > provide an option to suppress the warning? Not that much different > from having "fsmonitor.allowRemote" I suppose other than by default > fsmonitor would "just work" for network mounts. > > On Fri, Jul 1, 2022 at 2:41 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> writes: > > > > > Having said all of that, I did do lots of testing and never had an > > > issue with remote drives actually working correctly, so I think it'd > > > be fine allow a config setting to optionally allow it. I just didn't > > > want to clutter up things in advance if no one actually wanted to > > > use it on remote file systems. > > > > > > I think it would be fine to have a "fsmonitor.allowRemote" or > > > "fsmonitor.allowWindowsRemote" config setting and default them to false > > > for now. Or until we learn which combinations of remote mounts are > > > safe and/or problematic. > > > > How about getting rid of "is this remote?" check altogether (which > > presumably would simplify the logic) and make it totally up to the > > user of the repository? fsmonitor.disableInRepository that is set > > in ~/.gitignore and lists the paths to the repositories (like > > safe.directory does), for which fsmonitor gets disabled, may be a > > handy mechanism to set up the default (and it can be re-enabled with > > per-repository core.fsmonitor). > > > > After modifying the code and playing with it for a bit, I think simply removing the check (but still being able to report on it if tracing is enabled) is the way to go. Keep it simple and if new use cases arrive, deal with them then. -Eric
