Junio C Hamano <[email protected]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
