Re: git reset for index restoration?

From: David Turner <dturner@twopensource.com>
Date: May 22, 2014, 18:17 UTC
Message-ID: <1400782642.18134.8.camel@stross>
In-Reply-To: <CABPp-BHtYnput7SiAbnqUjpDibTi5o_2MAXfSj17fCdKSC7Hjg@mail.gmail.com>

On Thu, 2014-05-22 at 09:46 -0700, Elijah Newren wrote:

Show 21 quoted lines

> On Thu, May 22, 2014 at 9:22 AM, David Turner <dturner@twopensource.com> 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.
> >
> > Before I try to dig in to why this should be so, does anyone happen to
> > know off the top of their head?  Does this constitute a bug in git, or a
> > bug in my understanding of git?
> 
> It's not a bug.  The index has additional stat-info it tracks about
> files -- inode number, mtime, etc. -- so that it can quickly check
> whether files are up to date without comparing full file contents in
> the working copy to the relevant version from .git/objects.
> 
> 'git reset' means make the index match the commit in HEAD.

Sure, so why does git status the need to read the pack file, given that we already know that the index matches HEAD?

Show 8 quoted lines

>  It implies
> nothing about the working copy files, which could be different.
> Although you say that you have a clean working tree, git doesn't check
> to verify that, so it has to treat these files as stat-dirty until the
> next operation (e.g. git status) fills these in -- an operation that
> involves full comparison of the files in the working copy with the
> relevant version of the file from under .git/objects. (You may find
> 'git update-index --refresh' helpful here.)

In fact, git status does not write the index (at least in this context). And what is slow is not (only) checking over the working tree, but reading the packs. There should be no need to read files from the ODB at all, since the index knows those objects' SHA1s, and it can check those against the working tree's SHA1s. Interestingly, if strace is to be believed, git status doesn't even do check the working trees SHA1s after a git reset; maybe reset already sets the stat bits?

So that's why I'm confused.