top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

git reset for index restoration?

+1 vote
420 views

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?

posted May 22, 2014 by Garima Jain

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button
Are you sure it's reading a packfile? I would expect that it is rather reading the files in the working tree. One of the functions of the index is to maintain a cache of the sha1 of the working tree file content and the stat information. Once that is populated, a subsequent "git status" can then just lstat() the files to see that its sha1 cache is up to date.
commented May 22, 2014 by Seema Siddique

1 Answer

+1 vote

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.

answer May 22, 2014 by anonymous
Similar Questions
+1 vote
Git reset should be able to ignore file permissions

Recently I had to write some automation scripts and I found that git reset --hard actually restores each file's permissions.

That is causing both the created and the last-modified dates of the file to get changed to the time of the git reset.

This behavior is easy to demonstrate:

echo "test" > myfile
chmod 777 myfile

git add myfile && git commit -m "Test" & the only solution I'm able to think about is actually restoring the permissions of each file to the ones git thinks they should have before doing the git reset.

Maybe I'm wrong and there is a way for doing what I want, if so, please correct me. But if there isn't, should this be implemented? Are there any reasons for not doing it?

0 votes
Git pull silently removing files in the index

I think there's a bug in git pull. Doing a git pull in a fresh repository without any commits removes files in the index.

Example:

$ mkdir foo
$ cd foo
$ git init
$ touch file1 file2
$ git add file1
$ ls
file1 file2
$ git pull https://github.com/sos4nt/empty.git master
$ ls
file2

"file2" is still there, but "file1" was silently removed and no error message was shown.

I'm running git 1.8.3.1

0 votes
How to solve "Recv failure: Connection reset" issue?

Getting Recv Failure error while cloning the repository from bitbucket. Any idea to resolve this?

+1 vote
Can you tell me if GIT is free for educational use?

We would like to include it in our software master and have it installed on all computers. We are just double checking as some license agreements can be confusing.

+1 vote
Git for Windows 10 is saying corrupt or invalid?

I am using Windows 10 and am getting "The signature for git-2.7.0-64-bit.exe is corrupt or invalid" ! Same for the 32bit version.

Please help?

...