Martin von Zweigbergk <martinvonz@xxxxxxxxx> 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.
--
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