From: Tuncer Ayaz Date: Sun, 01 Feb 2009 22:48:30 GMT Subject: Re: [PATCH] bash: offer to show (un)staged changes Message-ID: <4ac8254d0902011448t242e7fcek3ae7fda609648ef0@mail.gmail.com> In-Reply-To: <20090119172939.GA14053@spearce.org> On Mon, Jan 19, 2009 at 6:29 PM, Shawn O. Pearce wrote: > Junio C Hamano wrote: >> Thomas Rast writes: >> >> > + if test ! -z "$GIT_PS1_EXPENSIVE"; then >> > + git update-index --refresh >/dev/null 2>&1 || w="*" >> >> This makes the feature unavailable for people who care about the stat >> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it? > > Yup, and I'm one of those people who sets autorefresindex to false > in my ~/.gitconfig, usually before I even have user.{name,email} set. > > I do like the idea of what Thomas is trying to do here, but its > so bloody expensive to compute dirty state on every prompt in > some repositories that I'd shoot myself. E.g. WebKit is huge, I've been thinking about this and wondered whether implementing "status --mini" or "status --short" which prints "+?*" in wt-status.c could be made fast enough. Should we try to implement and profile this or do we know it will be slow beforehand? I am actually using this feature on the bash prompt via calls to git commands and parsing for added=+, unknown=? and changed=* as others have done in combination with __git_ps1. > computing the dirty state inside of the WebKit repository on each > prompt would absolutely kill CLI performance to a point of it not > being usuable. But git.git is small enough its OK on pretty much > everything except Cygwin. > > So as much as I'd like to use this without the update-index --refresh > bit, I'm not sure its viable in every project out there. 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. > > -- > Shawn. > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >