Re: git reset for index restoration?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2014-05-23 at 06:33 +0700, Duy Nguyen wrote:
> On Fri, May 23, 2014 at 5:18 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > ... 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..

I am interested, and I believe I might be able to start looking into it
in a week or two.

--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]