Re: inotify daemon speedup for git [POC/HACK]

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jul 27, 2010, 23:29 UTC
Message-ID: <AANLkTinuU6b1vmRFuBrA4Tc5H6gmC5cMP3Pa8EYz-8JE@mail.gmail.com>
In-Reply-To: <20100727122018.GA26780@pvv.org>

On Tue, Jul 27, 2010 at 8:20 AM, Finn Arne Gangstad <finnag@pvv.org> wrote:

Show 9 quoted lines

> Reading through the thread about subtree I noticed Avery mentioning
> using inotify to speed up git status & co.
>
> Here is a quick hack I did some time ago to test this out, to use it
> call "igit" instead of "git" for all commmands you want to speed up.
>
> There is one minor nit: The speedup gain is zero :) git still
> traverses all directories to look for .gitignore files, which seems to
> totally kill the optimisation.

Hey, this is kind of cool.  Except for that last part :)

Actually I think the problem is a little worse than .gitignore files. 'git status', for example (which is called by git commit), wants to generate a list of the files it *doesn't* know about. Unfortunately, those files aren't in the index at all. So it resorts to doing recursive readdir() across the entire repository. The net result is about as slow as doing that plus one stat() per file in the index.

An inotify daemon could easily keep track of which files have been added that aren't in the index... but where would it put the list of files git doesn't know about? Do they go in the index with a special NOT_REALLY_INDEXED flag?

This is the main question that has so far prevented me from trying to solve the problem myself.

Thanks,

Avery