Re: speed of git reset -- file

Jeff King [off-list ref] 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...