Re: git reset for index restoration?

[David Turner <dturner@twopensource.com>]

On Thu, 2014-05-22 at 14:23 -0400, Jeff King wrote:
> On Thu, May 22, 2014 at 02:08:16PM -0400, David Turner wrote:
> 
> > On Thu, 2014-05-22 at 12:46 -0400, Jeff King wrote:
> > > On Thu, May 22, 2014 at 12:22:43PM -0400, David Turner wrote:
> > >
> > > > If I have a git repository with a clean working tree, and I delete the
> > > > index, then I can use git reset (with no arguments) to recreate it.
> > > > However, when I do recreate it, it doesn't come back the same.  I have
> > > > not analyzed this in detail, but the effect is that commands like git
> > > > status take much longer because they must read objects out of a pack
> > > > file.  In other words, the index seems to not realize that the index (or
> > > > at least most of it) represents the same state as HEAD.  If I do git
> > > > reset --hard, the index is restored to the original state (it's
> > > > byte-for-byte identical), and the pack file is no longer read.
> > >
> > > Are you sure it's reading a packfile?
> >
> > Well, it's calling inflate(), and strace says it is reading
> > e.g. .git/objects/pack/pack-....{idx,pack}.
> >
> > So, I would say so.
> 
> That seems odd that we would be spending extra time there. We do
> inflate() the trees in order to diff the index against HEAD, but we
> shouldn't need to inflate any blobs.

I just did a fresh clone of linux.git, and it doesn't have TREE (and
spends time in inflate).  Then I did a reset --hard, and it gained TREE
(and stopped spending time in inflate).  Then I did a checkout -b, and
TREE was lost again (time in inflate).  hard reset again (to HEAD, so no
change), and TREE returns and status is fast again.

Committing doesn't seem to create a TREE extension where one doesn't
exist.