Re: git reset for index restoration?
- From
David Turner <dturner@twopensource.com>
- Date
- May 22, 2014, 19:26 UTC
- Message-ID
- <1400786789.18134.27.camel@stross>
- In-Reply-To
- <20140522182303.GA1167@sigill.intra.peff.net>
On Thu, 2014-05-22 at 14:23 -0400, Jeff King wrote:
Show 25 quoted lines
> 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.