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:
To prepare for working on , switch to it by updating the index and the files in the working tree,
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:
To prepare for working on , switch to it by updating the index and the files in the working tree,
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.
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 likegit 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).
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 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.
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.
© 2022 - 2024 — McMap. All rights reserved.