On Thu, 2014-05-22 at 15:29 -0700, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html