From: Mike Hommey <mh@glandium.org>
Date: Mon, 19 Jan 2009 18:28:02 GMT
Subject: Re: [PATCH] bash: offer to show (un)staged changes
Message-ID: <20090119182802.GA10914@glandium.org>
In-Reply-To: <20090119181158.GH14053@spearce.org>

On Mon, Jan 19, 2009 at 10:11:58AM -0800, Shawn O. Pearce wrote:
> Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > On Mon, Jan 19, 2009 at 12:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > > ...  If we had
> > > an inotify sort of daemon to keep the data current so the prompt
> > > doesn't have to stat every source file on every display it would
> > > be reasonable, but we don't have such a thing yet for Git.
> > 
> > Note that inotify is not recursive and is a hog if you ask it to
> > monitor lots of dents.
> > 
> > I am not convinced that an inotify-enabled git is a good idea for
> > anything but small/mid-sized project. And such don't need it either.
> > 
> > In other words, the kernel's cache will outperform any userland
> > attempting to keep track of the fs via inotify.
> 
> *sigh*
> 
> I was hoping it would work well for the really huge repository case,
> like WebKit, where the stats against the work tree just kill the
> user space application.

I was hoping something like that too, especially for cold cache cases,
after resuming from hibernation, for instance, in which case the kernel
cache is empty and inotify tracking will help know if something changed.

Mike