On Thu, May 25, 2017 at 3:55 PM, Ben Peart <peartben@xxxxxxxxx> wrote: > > > On 5/24/2017 6:54 AM, Christian Couder wrote: >>> >>> Design >>> ~~~~~~ >>> >>> A new git hook (query-fsmonitor) must exist and be enabled >>> (core.fsmonitor=true) that takes a time_t formatted as a string and >>> outputs to stdout all files that have been modified since the requested >>> time. >> >> >> Is there a reason why there is a new hook, instead of a >> "core.fsmonitorquery" config option to which you could pass whatever >> command line with options? > > > A hook is a simple and well defined way to integrate git with another > process. If there is some fixed set of arguments that need to be passed to > a file system monitor (beyond the timestamp stored in the index extension), > they can be encoded in the integration script like I've done in the Watchman > integration sample hook. Yeah, they could be encoded in the integration script, but it could be better if it was possible to just configure a generic command line. For example if the directory that should be watched for filesystem changes could be passed as well as the time since the last changes, perhaps only a generic command line would be need. I am also wondering about sparse checkout, as we might want to pass all the directories we are interested in. How is it supposed to work with sparse checkout? >>> A new 'fsmonitor' index extension has been added to store the time the >>> fsmonitor hook was last queried and a ewah bitmap of the current >>> 'fsmonitor-dirty' files. Unmarked entries are 'fsmonitor-clean', marked >>> entries are 'fsmonitor-dirty.' >>> >>> As needed, git will call the query-fsmonitor hook proc for the set of >>> changes since the index was last updated. Git then uses this set of >>> files along with the list saved in the fsmonitor index extension to flag >>> the potentially dirty index and untracked cache entries. >> >> >> So this can work only if "core.untrackedCache" is set to true? >> > > This works with core.untrackedCache set to true or false. If it is set to > false, you get valid results, you just don't get the speed up when checking > for untracked files. Great!