Hi Junio, On Fri, 3 Feb 2017, Junio C Hamano wrote: > 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... I am not sure... when you run `git diff` and `git status`, the index is refreshed *anyway*, so with the patch under discussion we would save one round of lstat() calls, for the same effect. I could imagine that there is a third option we should consider, too: only lstat() and update the paths that match the pathspec(s) provided on the command line (this is the semantic meaning of the --only option, after all: "I am only interested in these paths as far as this commit is concerned"). What do you think? Ciao, Johannes