David Turner <dturner@xxxxxxxxxxxxxxxx> writes: >> 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. -- 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