git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git reset for index restoration?

From
Elijah Newren <newren@gmail.com>
Date
May 22, 2014, 16:46 UTC
Message-ID
<CABPp-BHtYnput7SiAbnqUjpDibTi5o_2MAXfSj17fCdKSC7Hjg@mail.gmail.com>
In-Reply-To
<1400775763.1933.5.camel@stross>
On Thu, May 22, 2014 at 9:22 AM, David Turner <dturner@twopensource.com> wrote:
Show 13 quoted lines
> 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.

Previous: David TurnerNext: David Turner
Message 6 of 22 in “git reset for index restoration?”
  1. David TurnerMay 22, 2014
  2. Jeff KingMay 22, 2014
  3. David TurnerMay 22, 2014
  4. Jeff KingMay 22, 2014
  5. David TurnerMay 22, 2014
  6. Elijah NewrenMay 22, 2014
  7. David TurnerMay 22, 2014
  8. Jeff KingMay 22, 2014
  9. David TurnerMay 22, 2014
  10. Jeff KingMay 22, 2014
  11. Jeff KingMay 22, 2014
  12. Junio C HamanoMay 22, 2014
  13. David TurnerMay 22, 2014
  14. Junio C HamanoMay 22, 2014
  15. David TurnerMay 22, 2014
  16. Junio C HamanoMay 22, 2014
  17. Junio C HamanoMay 22, 2014
  18. Duy NguyenMay 22, 2014
  19. David TurnerMay 22, 2014
  20. Junio C HamanoMay 22, 2014
  21. David TurnerMay 22, 2014
  22. Junio C HamanoMay 22, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.