Re: [RFC] On watchman support

From: Duy Nguyen <pclouds@gmail.com>
Date: Nov 13, 2014, 12:22 UTC
Message-ID: <CACsJy8AKsvL2XcBMGG1Jy_W2KaOCuYm16Ffk529KDOARr68XNQ@mail.gmail.com>
In-Reply-To: <54643C30.6010204@web.de>

On Thu, Nov 13, 2014 at 12:05 PM, Torsten Bögershausen <tboegi@web.de> wrote:

Show 17 quoted lines

> 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.

Hmm.. you remind me mtime series may have this as an advantage over watchman..

-- 
Duy