Aside from whitespace breakage, I think we should never skip the refreshing of the real index that is left after "git commit" finishes. Between these two calls to refresh_cache(), the one that writes out a temporary index that contains the contents of HEAD plus the contents of the working tree for the specified paths may be fine without refreshing, unless somebody else (like the pre-commit hook) looks at it. But the other one refreshes the real index file that will be used after "git commit" returns the control. Users and scripts that run "git commit" inside expect that the entries in the resulting index are refreshed after "git commit" returns, and I do not think of a safe way to optimizing it out; unlike the other one, to which we can say "as long as there is no pre-commit hook, nobody will look at it after we are done", there does not an easy-to-check set of conditions that we can use to decide when it is safe to skip refreshing. Besides, leaving the main index not refreshed would mean the user has to pay the refreshing cost when s/he runs other commands "git diff", "git status", etc. after "git commit" for the first time; so...