Subject: Re: git reset for index restoration?

From: Junio C Hamano <[email-masked]>
Date: Thu, 22 May 2014 15:29:24 -0700

Junio C Hamano <[email-masked]> writes:

> 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.

Here is what I tried just now.

    $ rm .git/index
    $ git read-tree HEAD HEAD

Note that a single-tree read-tree will populate the cache-tree and
that is why I am forcing "switch branches" 2-way read-tree here,
which I know will discard the cache-tree fully.

    $ ls -l .git/index
    -rw-r----- 1 jch eng 249440 May 22 15:20 .git/index
    $ git checkout HEAD^0
    $ ls -l .git/index
    -rw-r----- 1 jch eng 249440 May 22 15:21 .git/index

Still the same size, without cache-tree.

    $ git write-tree
    57361c4add61b638dad1c1c2542edf877f515c48
    $ ls -l .git/index
    -rw-r----- 1 jch eng 254383 May 22 15:21 .git/index

The size differences come from the recomputation of the cache tree.
The result is the same if we replace "git write-tree" with a
whole-index commit, e.g.

    $ git commit --allow-empty -m foo

and test-dump-cache-tree seem to see a fully populated cache-tree
after these steps.