On 9/15/2017 3:43 PM, David Turner wrote:
-----Original Message-----
From: Ben Peart [mailto:benpe...@microsoft.com]
Sent: Friday, September 15, 2017 3:21 PM
To: benpe...@microsoft.com
Cc: David Turner <david.tur...@twosigma.com>; ava...@gmail.com;
christian.cou...@gmail.com; git@vger.kernel.org; gits...@pobox.com;
johannes.schinde...@gmx.de; pclo...@gmail.com; p...@peff.net
Subject: [PATCH v6 05/12] fsmonitor: add documentation for the fsmonitor
extension.
This includes the core.fsmonitor setting, the query-fsmonitor hook, and the
fsmonitor index extension.
Signed-off-by: Ben Peart <benpe...@microsoft.com>
---
Documentation/config.txt | 6 ++++++
Documentation/githooks.txt | 23 +++++++++++++++++++++++
Documentation/technical/index-format.txt | 19 +++++++++++++++++++
3 files changed, 48 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt index
dc4e3f58a2..c196007a27 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -413,6 +413,12 @@ core.protectNTFS::
8.3 "short" names.
Defaults to `true` on Windows, and `false` elsewhere.
+core.fsmonitor::
+ If set, the value of this variable is used as a command which
+ will identify all files that may have changed since the
+ requested date/time. This information is used to speed up git by
+ avoiding unnecessary processing of files that have not changed.
I'm confused here. You have a file called "fsmonitor-watchman", which seems to
discuss the protocol for core.fsmonitor scripts in general, and you have this
documentation, which does not link to that file. Can you clarify this?
I'll add the missing link to the documentation in githooks.txt. The
documentation should be enough for someone to develop another
integration script.
The fsmonitor-watchman script allows people to easily use this patch
series with the existing Watchman monitor but it can certainly also be
used as a sample for how to integrate with another file system monitor.
<snip>
+The hook should output to stdout the list of all files in the working
+directory that may have changed since the requested time. The logic
+should be inclusive so that it does not miss any potential changes.
+"It is OK to include files which have not actually changed. Newly-created and
deleted files should also be included. When files are renamed, both the old and the new
name should be included."
Also, please discuss case sensitivity issues (e.g. on OS X).
+The paths should be relative to the root of the working directory and
+be separated by a single NUL.
<snip>
+ - 32-bit version number: the current supported version is 1.
+
+ - 64-bit time: the extension data reflects all changes through the given
+ time which is stored as the nanoseconds elapsed since midnight,
+ January 1, 1970.
Nit: Please specify signed or unsigned for these. (I expect to be getting out
of
cryosleep around 2262, and I want to know if my old git repos will keep
working...)
While I'm not opposed to specifying unsigned, I did notice that the only
place signed/unsigned is specified today is in "index entry." Everywhere
else doesn't specify so I left it off for consistency. I've not seen
negative version numbers nor negative time so am not entirely sure it is
necessary to clarify. :)
+ - 32-bit bitmap size: the size of the CE_FSMONITOR_VALID bitmap.
+
+ - An ewah bitmap, the n-th bit indicates whether the n-th index entry
+ is not CE_FSMONITOR_VALID.
