Re: [PATCH] reset: trivial refactoring

Martin von Zweigbergk [off-list ref] writes:

...the line after this one reads

   err = reset_index(sha1, MIXED, quiet);

? I don't know what the consequence of not calling prime_cache_tree()
would be, though.

It does not affect correctness, but makes the subsequent "git
status", the part that internally computes "diff-cache --index" to
see what changes have been added to the index, more costly.

After doing "reset --hard $commit" or just "reset $commit", we know
that the contents of the index must match $commit^{tree}, and
writing out any subpart of the index that corresponds to a directory
(including the top-level one, i.e. the whole index) must match the
corresponding subtree of $commit^{tree}.  And that is why we prime
the cache-tree that was discarded by unpack_trees() at the very end.
Then incremental "git add" to the resulting index after that can
invalidate only the parts of the index and cache-tree while
relieving the next "write-tree" (most often done by the next "git
commit") from having to compute the tree objects for parts of the
index that have not been touched since the "reset" operation.

I do not use "reset --keep $commit" very often myself, but IIRC, it
is like "checkout $commit" (and not "checkout -m $commit") in that
the resulting index matches $commit^{tree}, so I think priming the
cache-tree just like --hard/--mixed is the right thing to do.