Re: git reset for index restoration?

From: Duy Nguyen <pclouds@gmail.com>
Date: May 22, 2014, 23:33 UTC
Message-ID: <CACsJy8Bh+igRNsV0nCQ84EvvOh_ye3pqoTi3g_5ix_1LgX-EvQ@mail.gmail.com>
In-Reply-To: <xmqq1tvlmp8w.fsf@gitster.dls.corp.google.com>

On Fri, May 23, 2014 at 5:18 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> ... and the "incrementally repair" Peff talks about would be to
> cover more cases where we may know (either because we have already
> computed it to write out a subtree, or we have just read from a
> known tree to populate a part of the index and we know the paths in
> the index that correspond to that subtree are exactly the same ones
> as found in the tree we read from) parts of the cache-tree can be
> updated with tree object names for subtrees, but we don't do
> anything right now.

I wanted to do this but it's hard. For "diff --cached" (which should be where we find out and repair cache-tree), we flatten the trees in traverse_trees() and let unpack-trees figure out the differences against the index. The's no direct connection between a change and a tree. Maybe I missed something. David if you are interested in "git status" performance, this repairing thing could be important when the worktree is large because the diff cost increases accordingly if cache-tree is not fully populated. Empty cache-tree could cost us nearly the same time we save with avoiding opendir/readdir..

-- 
Duy