On Thu, May 22, 2014 at 9:22 AM, David Turner <dtur...@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. 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.) git reset --hard means not only make the index match the commit in HEAD, but change files in the working copy to match as well. In such a case, git will know that the index matches the working copy (since it is enforcing it), so it can update all the stat-info in the index and future git-status operations will be fast. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
