Re: [RFC] On watchman support

["Torsten Bögershausen" <tboegi@web.de>]

On 11/13/2014 01:22 PM, Duy Nguyen wrote:
> On Thu, Nov 13, 2014 at 12:05 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>> From a Git user perspective it could be good to have something like this:
>>
>> a) git status -u
>> b) git status -uno
>> c) git status -umtime
>> d) git status -uwatchman
>>
>> We know that a) and b) already exist.
>> c) Can be convenient to have, in order to do benchmarking and testing.
>>   When the UNTR extension is not found, Git can give an error,
>>   saying something like this:
>>   No mtime information found, use "git update-index --untracked-cache"
>> d) does not yet exist
>>
>> Of course we may want to configure the default for "git status" in a default variable,
>> like status.findUntrackedFiles, which can be empty "", "mtime" or "watchman",
>> and we may add other backends later.
> While "git status" is in the spotlight, these optimizations have wider
> impact. Faster index read/refresh/write helps the majority of
> commands. Faster untracked listing hits git-status, git-add,
> git-commit -A... This is why I go with environment variable for
> temporarily disabling something, or we'll need many config and command
> line options, one per command.
>
>> A short test showed that watchman compiles under Mac OS.
>> The patch did not compile out of the box (both Git and watchman declare
>> there own version of usage(), some C99 complaints from the compiler in watchman,
>> nothing that can not be fixed easily)
> Yeah it's not perfect. It's mainly to show speeding up refresh with
> watchman could be done easily and with low impact
>
>> I will test the mtime patch under networked file systems the next weeks.


Thinks become to get a little bit clearer.
What I can understand is that we have 2 different "update-helpers" for Git,
thanks for that.

just in case there is re-roll, does the following makes sense:
We want to enable them (probably only one at a time) either by command line or
persistent in a repo.

As I think we have 2 different update helpers
(and may be more in the future)
GIT_UPDATE_HELPER=dirmtime git status
GIT_UPDATE_HELPER=watchman git status
GIT_UPDATE_HELPER=none git status

of course we want to be able to configure it:
git config core.updatehelper dirmtime


After configuring we may want to override it:
GIT_UPDATE_HELPER=none git status
or
git -c core.updatehelper=none status

> Hmm.. you remind me mtime series may have this as an advantage over watchman..
I had the time to do a short test, sharing a copy of git.git under NFS:
The time for git status dropped from 0.4 seconds to 0.15 seconds or so.
Very nice.
The next test will be to share the same repo under samba to Windows
and Mac OS and see how this works.