Re: inotify to minimize stat() calls

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 14, 2013, 15:16 UTC
Message-ID: <CACBZZX6BVuQWtrLuTVXZo+77sT4yZQ3pvN=_fMma24-zd0NNqA@mail.gmail.com>
In-Reply-To: <CALkWK0=EP0Lv1F_BArub7SpL9rgFhmPtpMOCgwFqfJmVE=oa=A@mail.gmail.com>

On Fri, Feb 8, 2013 at 10:10 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 6 quoted lines

> For large repositories, many simple git commands like `git status`
> take a while to respond.  I understand that this is because of large
> number of stat() calls to figure out which files were changed.  I
> overheard that Mercurial wants to solve this problem using itnotify,
> but the idea bothers me because it's not portable.  Will Git ever
> consider using inotify on Linux?  What is the downside?

There's one relatively easy sub-task of this that I haven't seen mentioned: Improving the speed of interactive rebase on large (as in lots of checked out files) repositories.

That's the single biggest thing that bothers me when I use Git with large repos, not the speed of "git status". When you "git rebase -i HEAD~100" re-arrange some patches and save the TODO list it takes say 0.5-1s for each patch to be applied, but at least 10x less than that on a small repository. E.g. try this on linux-2.6.git v.s. some small project with a few dozen files.

I looked into this a long while ago and remembered that rebase was doing something like a git status for every commit that it made to check the dirtyness.

This could be vastly improved by having an unsafe option to git-rebase where it just assumes that the starting state + whatever it wrote out is the current state, i.e. it would break if someone stuck up on your checkout during an interactive rebase and changed a file, but the common case of the user having exclusive access to the repo and waiting for the rebase would be much faster.