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). -Peff [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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html