Why do checkout and reset change the index?
Asked Answered
I

3

1

I thought that the index is just for the files you staged for the next commit, but both reset and checkout also update the index:

git checkout

To prepare for working on , switch to it by updating the index and the files in the working tree,

Indole answered 11/1, 2014 at 18:42 Comment(0)
I
1

The idea is that git always commits snapshots of the current state and not just diffs. So when doing a checkout, the index will be updated to contain a snapshot of what you just checked out, which you then change adding files/changes.

My question is because I operated under the incorrect assumption that only changes would be added to the index.

Indole answered 11/1, 2014 at 20:6 Comment(1)
+1. That echoes my answer where a checkout allows you to "start staging your work against that content.Dinesen
D
5
  • git reset can change just HEAD (git reset --soft), or HEAD and index (default), or HEAD index and working tree (git reset --hard).
  • git checkout can change the index only when switching branch, in order for you to start staging your work against the content of that branch.

That discussion points out why checkout changes the index:

my understanding of the index is that it is the middle-man for:

  • moving things from your work-tree to the object-store
  • AND for moving things from the object-store to your work-tree.

Therefore, when you checkout the blob, it first gets copied from the object-store to your index and then from the index to your work-tree.


torek mentions in the comments something that reflects another part of the same thread:

Note that you can bypass the write through the index by using git show to extract the file:

git show HEAD~3:file > file 

will overwrite the working directory version of file, much like git checkout HEAD~3 -- file would, but will not update the index.

I present git show in more detail at "How to retrieve a single file from specific revision in Git?".

Note also that git-show doesn't apply filters to the file (smudge/clean or any custom ones).

Dinesen answered 11/1, 2014 at 18:54 Comment(2)
Note that you can bypass the write through the index by using git show to extract the file: git show HEAD~3:file > file will overwrite the working directory version of file, much like git checkout HEAD~3 -- file would, but will not update the index.Inlaw
@Inlaw Good point. I have included your comment, with some additional links, to the answer for more visibility.Dinesen
K
1

After a clean checkout or reset the content of HEAD is the same as the Index and the content of the working tree.

Afterwards you usually change your working tree, then update the index using git add and finally turn the resulting index into a commit using git commit.

The index works very similar as your working tree: You start by the content current commit change some files and finally make the result a commit.

If you change your current commit using git checkout or git reset, the index has to change, to allow you to change it in order to create a new commit.

Knickerbockers answered 11/1, 2014 at 18:51 Comment(0)
I
1

The idea is that git always commits snapshots of the current state and not just diffs. So when doing a checkout, the index will be updated to contain a snapshot of what you just checked out, which you then change adding files/changes.

My question is because I operated under the incorrect assumption that only changes would be added to the index.

Indole answered 11/1, 2014 at 20:6 Comment(1)
+1. That echoes my answer where a checkout allows you to "start staging your work against that content.Dinesen

© 2022 - 2024 — McMap. All rights reserved.