Re: git reset for index restoration?

David Turner [off-list ref] writes:

quoted

Yes.  As I said, that should not usually be a problem for those who
do the real work (read: commit), at which time write-tree will fully
populate the cache-tree.

Git commit does not in fact populate the cache-tree.

If that is the case, we must have broken the write-tree codepath
over time.

Of course, "git commit foo" will need to prepare a temporary index
where only the entry "foo" is different from the HEAD version, write
the tree to create a commit, but we do not write out the main index
as a tree after updating the same entry "foo" in it (there may be
other changes relative to HEAD), so its cache-tree is only
invalidated at "foo" when we updating the entry and we do not spend
extra cycles to repopulate it.

But at least my understanding has been that "git commit" (no partial
commit, write the whole index as a commit) which uses the "git
write-tree" machinery knows which subtree has what tree object name
and populates the cache-tree fully.