Re: git reset for index restoration?

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> David Turner <dturner@twopensource.com> 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.

... and the "incrementally repair" Peff talks about would be to
cover more cases where we may know (either because we have already
computed it to write out a subtree, or we have just read from a
known tree to populate a part of the index and we know the paths in
the index that correspond to that subtree are exactly the same ones
as found in the tree we read from) parts of the cache-tree can be
updated with tree object names for subtrees, but we don't do
anything right now.  "git commit foo" (where "foo" is a directory)
may be able to say "The cache-tree entry for 'foo' can be updated
with the tree object of the new HEAD:foo because we know they must
match in the main index", for example.