On Thu, 2014-05-22 at 15:29 -0700, Junio C Hamano wrote:
> Junio C Hamano <gits...@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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to