git status) in a working directory with many files. Like hook-based file system monitors, the built-in file system monitor can speed up Git commands that need to refresh the Git index (e.g. The documentation also explains why we might want a filesystem monitor in the first place, and why a built-in monitor is preferable: (The older documentation reveals that this setting did exist prior to this change, but it was used for pointing to an external command to use as a monitor.) If set to true, enable the built-in file system monitor daemon for this working directory Indeed, if we look at the documentation for core.fsmonitor, we see that this is the case¹: The hints you quote in your question suggest that this feature is now considered stable enough to be the default. It can be turned on by setting both feature.manyFiles=true and feature.experimental=true (or directly, via eBuiltinFSMonitor=true).Ĭore.useBuiltinFSMonitor is not documented on the Git website, even on an older version where it should exist, but it appears to have been a setting to enable the built-in filesystem monitor for users who want to live on the bleeding edge. Git for Windows now ships with an experimental built-in file-system monitor, without the need to install Watchman and setting core.fsmonitor. The release notes for Git for Windows 2.30.2 (March, 2021) offer some clues: (And if they know they have multiple versions, they can just set both for now.) Link So it's safer to just warn the user and let them decide. So, auto transitioning it would break whichever one is the older release. And these may be at different revision levels, so one install might only understand the old keyword and one version might understand both (during the transition). and hidden versions installed by tools like Visual Studio. However, users may have multiple versions of Git installed on their systems on Windows. With the feature going upstream into core Git, a decision was made to overload the existing core.fsmonitor setting to take a hook-pathname or a boolean value for the builtin FSMonitor. And finnaly, the reason for the prompt:.I guess we should clarify by saying eBuiltinFSMonitor=true was experimental, please set core.fsmonitor=true` instead. So I understand that the builtin FS monitor is not actually deprecated, just that the name in the config is going to change, is there, on the current version, any way to use the new name or is the only way to get rid of the message to disable it via the provided command? In a recent post they seemed to have addressed this issue.The new FSMonitor feature is controlled by the eBuiltinFSMonitor boolean. Seems like both of them are interconnected and hence they haven't yet disabled one.The answer to the what is in Chris's answer and to why is below. One can safely use the command git config -global core.fsmonitor true to get rid of the message for good. Thanks to Chris for the explanation and links to look around.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |