Watchman Makes Fsnotify Spuriously Detect File Changes

watchman: I am missing file deletions happening before subscription

The issue is that you're using a since expression term rather than informing watchman to use the since generator (the recency index).

What's the difference? You can think of this as the difference between the FROM and WHERE clauses in SQL. The expression field is similar in intent to the WHERE clause: it applies to the matched results and filters them down, but what you wanted to do is specify the FROM clause by setting the since field in the query spec. This is admittedly a subtle difference.

The solution is to remove the expression term and add the generator term like this:

q = w.query('subscribe', '/tmp/z', 'Buffy', 
            {"since": clock,
             "fields": ["name", "exists", "oclock",
                        "ctime_ns", "new", "mode"]})

While we don't have really any documentation on the use of the pywatchman API, you can borrow the concepts from the slightly better documented nodejs API; here's a relevant snippet:

https://facebook.github.io/watchman/docs/nodejs.html#subscribing-only-to-changed-files

Prevent watchman from triggering during file upload?

I was able to work around this issue by adjusting the "settle" parameter. Apparently the default of 20 ms is too low for network transfers, resulting in periods where the disk is idle as incoming data is buffered or something. By bumping this setting up to 500, watchman no longer triggers before the file transfer is complete.

How to start git daemon on Windows

Git for Windows 1.7.4 includes support for git daemon on windows which was missing in previous versions. To export your repository you will need to create a file called git-daemon-export-ok in the .git directory or include the --export-all command line option.

In a git repository run:git daemon --export-all and you can then connect to it from a remote machine eg: git ls-remote git://yourmachine/path/to/repo

Is it safe to set git's core.precomposeunicode = true globally?

No, that won't work. There is no such thing as a central git server in a distributed version control system - at least not in the technical sense.

Each developer has his own repository to which he checks in his changes. When those changes are pushed to the repository you declare as central, the data is not re-processed.

You will have to set that configuration on every local repository.

Unfortunately, there is no alternative with .gitattributes either.

Local options for a certain repository that will then be cloned by the developers isn't an option either. The following simple experiment shows this:

d:\Temp\Origin>git init
Initialized empty Git repository in d:/Temp/Origin/.git/

d:\Temp\Origin>git config --local --add core.autocrlf input
d:\Temp\Origin>git config --local --list
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.autocrlf=input
d:\Temp\Origin>cd ..
d:\Temp>git clone d:\Temp\Origin Developer
Cloning into 'Developer'...
warning: You appear to have cloned an empty repository.
done.

d:\Temp>cd Developer

d:\Temp\Developer>git config --local --list
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
remote.origin.url=d:\Temp\Origin
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master

Note how the call to git config --local --list in Origin lists core.autocrlf=input and the same command in Developer doesn't, although we just cloned Developer from Origin.

That demonstrates that repository-local configuration values are not cloned.

---

Related Topics