Re: [PATCH] reset: trivial refactoring

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 13, 2013, 21:34 UTC
Message-ID: <7v38slu23u.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CANiSa6i5xL-V+W46zWXGzLc+dSO6a+V0BLPt7hFgGZGXpp03BQ@mail.gmail.com>

Martin von Zweigbergk <martinvonz@gmail.com> writes:

Show 6 quoted lines

> ...the line after this one reads
>
>    err = reset_index(sha1, MIXED, quiet);
>
> ? I don't know what the consequence of not calling prime_cache_tree()
> would be, though.

It does not affect correctness, but makes the subsequent "git status", the part that internally computes "diff-cache --index" to see what changes have been added to the index, more costly.

After doing "reset --hard $commit" or just "reset $commit", we know that the contents of the index must match $commit^{tree}, and writing out any subpart of the index that corresponds to a directory (including the top-level one, i.e. the whole index) must match the corresponding subtree of $commit^{tree}. And that is why we prime the cache-tree that was discarded by unpack_trees() at the very end. Then incremental "git add" to the resulting index after that can invalidate only the parts of the index and cache-tree while relieving the next "write-tree" (most often done by the next "git commit") from having to compute the tree objects for parts of the index that have not been touched since the "reset" operation.

I do not use "reset --keep $commit" very often myself, but IIRC, it is like "checkout $commit" (and not "checkout -m $commit") in that the resulting index matches $commit^{tree}, so I think priming the cache-tree just like --hard/--mixed is the right thing to do.