Jeff King <peff@xxxxxxxx> writes: > So implementing the "optimization" to drop the refresh here doesn't seem > worth it. It inroduces an awful inconsistency, and it probably isn't > saving much in practice... You could make it less inconsistent by introducing core.autorefreshindex for people who _do_ care about the latency. We already have a precedent in diff.autorefreshindex and the new configuration would supercede it. Usually we refresh the cached lstat information in the index at strategic places so that later operations do not have to pay the penalty, but at the same time, the higher level commands that want to make sure they are not fooled by stale lstat differences do refresh the index themselves anyway, so leaving cached stat information stale is not exactly the end of the world. All the high-level commands like "reset" that do _not_ absolutely need to refresh the index for them to work, but do refresh the index to help later invocation of other commands, could be taught to pay attention to the core.autorefreshindex. After many operations the users usually do not see changes from diff-files, people who set this to false will see phantom changes due to stale cached lstat information, and they will see them consistently. They know exactly when having up-to-date lstat information in the index really matters, and they will run "update-index --refresh" themselves when needed. I however personally doubt it would be worth the effort. The _only_ person who complained about this doesn't even use "update-index --refresh" but uses "git status", which does more than refreshing the index, and seems to think the extra latency coming from the overhead is acceptable. So... -- 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