Re: [PATCH] bash: offer to show (un)staged changes

[Tuncer Ayaz <tuncer.ayaz@gmail.com>]

On Mon, Jan 19, 2009 at 6:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>> Thomas Rast <trast@student.ethz.ch> 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
>