On Tue, Aug 07, 2007 at 08:32:55AM +0200, David Kastrup wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Matthieu Moy <Matthieu.Moy@xxxxxxx> writes: > > > >> Unfortunately, the patch solves the "large and irrelevant output" > >> of git-diff, but not the performance problem (see the rest of the > >> thread, I failed to convince Junio that updating the index was a > >> performance improvement while keeping the same user semantics). > > > > That's what update-index --refresh (or status if you insist) are > > for, and the coalmine canary you are so dead set to kill are helping > > you realize the need for running. > > That does not convince me. Cache staleness should be a problem of > git, not of the user. In particular if the user is just using > porcelain. If letting the cache get stale impacts performance, then > git should clean up its act on its own without barfing when using > unrelated commands. If it notices this during diff (presumably by > overstepping some staleness ratio), then it can set a "regenerate on > next opportunity" flag on the index, and then the next command wanting > to process the index from the start can rewrite a refreshed version. The last time I had a serious problem with "cache staleness", it was with Beagle, which modifies the files it indexes (by writing some extended attributes). I figured out what was happening when I noticed that the list of touched files was growing each time I did a diff (implying the something was working on them right then), so I ran top, noticed beagled, eventually thought to query the extended attributes, and finally turned off beagled's indexing to solve the problem. So, in this case: - If git had fixed up the problem silently, I probably would have just assumed git was slow and not found the problem. - Seeing the actual list of files for which the index was dirty helped me identify the problem. I probably would have eventually figured it out even if all I'd had was a single "index is stale" message, but I suspect it would have taken longer. Draw whatever moral you'd like.... --b. - 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
