On Sun, Sep 30, 2012 at 01:34:58PM -0700, Jonathan Nieder wrote:

> Jeff King wrote:
> > On Sun, Sep 30, 2012 at 10:05:27AM +1000, Paul Mackerras wrote:
> >> Unfortunately this will wait for the git update-index command to
> >> complete, making the GUI unresponsive while it executes, and that can
> >> take minutes on a large repository (e.g. the linux kernel) on a
> >> machine with a slow disk and a cold disk cache.  We will need to make
> >> the git update-index execute asynchronously.
> >
> > Good point. We're getting out of my very limited tcl cargo-culting
> > skills now, so I'll let somebody more clueful do that fix.
> You might find the following patch and discussion entertaining:
>   http://thread.gmane.org/gmane.comp.version-control.git/144182
> Not my itch, but it was fun to write back then. ;-)

Not really my itch either, which is why I'm trying to dump the tcl work
on somebody else. :) For what it's worth, your patch from that thread
looks like a sane approach.

I don't buy the "gitk should be read-only" argument from that thread. I
think we decided a while back[1] that the stat cache is not really a
user-visible modification; you're not updating the index in any
meaningful way that impacts the user's workflow, but merely refreshing
our cache of what is in the filesystem.  That may have performance
implications (which is why we do not do it in all commands by default),
but it really is a cache, and updating it should be no different than
updating gitk.cache (i.e., do it if we can, but do not complain if we
are in a read-only repository).


[1] I did not track down the threads, but I consider this resolved by
    all of the discussion that led to "git diff" refreshing (and saving)
    the index rather than printing patch-less stat-dirty entries. The
    original argument against refreshing was that the stat-dirtiness was
    somehow interesting to users, but I think experience has shown that
    people are happy to have it happen magically behind the scenes.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to