Re: git reset for index restoration?

From: David Turner <dturner@twopensource.com>
Date: May 22, 2014, 23:02 UTC
Message-ID: <1400799746.18134.48.camel@stross>
In-Reply-To: <xmqqwqddla63.fsf@gitster.dls.corp.google.com>

On Thu, 2014-05-22 at 15:29 -0700, Junio C Hamano wrote:

Show 37 quoted lines

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

I get the same results as you with git write-tree. But I do not get the same results from a whole-index git commit (I tried your exact command-line). That is, when I do git commit with no cache-tree in place, it does not create one.

To expand: even if git commit did work for me the way it seems to work for you, I still believe that the cache-tree behavior would be suboptimal, because every time a user switches branches, they lose their cache-tree, and thus all of their git status commands are slow until their first commit. But I am willing to believe that my workflow is atypical, and that most people commit enough soon after switching branches.