On Mon, Jan 19, 2009 at 6:29 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Thomas Rast <trast@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
