Git and three copies of a file

I ran into git ls-files today, which I don’t normally use, and one of the top search results led me to this stackoverflow answer. It is very useful, so I’ll make note to myself, to try and remember it this time.

• You have a .git, which is the “repository”, and the files right next to it which is the “work-tree”. Also in the repo, but not commited is the “index”.

• The files in the “repo” are stored in the git format, and grouped into commits.

• The files in “worktree” are regular files.

• The files in “index” are a stored version of the worktree

• git add file will take the worktree copy of the file, and add it to the index.

• So now you git commit, it takes the index and packages all of’em into a commit and adds the commit to a repository. So now I have three copies of my file in git: one (normal file) in my worktree. One git-formatted in index. And one in some of the commits somewhere.

• Potentially when I git merge or something, I’ll get fourth and maybe even fifth copy of the file.

So, you checkout a file, so your repo index.html, your index.html and worktree index.html are all the same. Then you change the file, so your repo and index are the same, but the worktree file is different. Then you e.g. git add it, and now your repo differs from index and worktree. Or e.g. you make a further edit, so now all three of them are different copies.

• Interestingly, this explains why creating a new file is fun, git commit doesn’t care. It has it in worktree but not in index, and that’s where the commit is going from, index.