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. -- David Kastrup - 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
