Re: git reset for index restoration?

From: Junio C Hamano <gitster@pobox.com>
Date: May 22, 2014, 22:29 UTC
Message-ID: <xmqqwqddla63.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqq61kxmphw.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> 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.