On 5/27/2017 2:57 AM, Christian Couder wrote:
On Thu, May 25, 2017 at 3:55 PM, Ben Peart <peart...@gmail.com> 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.
Maybe I'm not understanding what you have in mind but I haven't found
this to be the case in the two integrations I've done with file system
watchers (one internal and Watchman). They require you download,
install, and configure them by telling them about the folders you want
monitored. Then you can start querying them for changes and processing
the output to match what git expects. While the download and install
steps vary, having that query + process and return results wrapped up in
an integration hook has worked well.
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?
The fsmonitor code works well with or without a sparse-checkout. The
file system monitor is unaware of the sparse checkout so will notify git
about any change irrespective of whether git will eventually ignore it
because the skip worktree bit is set.
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!
