Why do I need to tell git I've removed a file?

I'm building a historical record of development into git from saved zip files. I'm happy about the need to git add . files to the staging area so that the selected files are committed. So far so good.

However I'm now in the situation of simply adding the first (unzipped) file set, committing them, then deleting their directory and contents, before unzipping the next set, adding them and committing, often with variant directory names.

My problem of understanding is that I'm getting "unstaged changes" showing (Git Gui) of directorie/files I deleted a few commits back. I understood that git takes a snapshot of the current files, so shouldn't have any deleted files in there.

So, have my recent commits contained copies (in their tree) of those deleted files? When/why does git rm need to be used instead of a plain rm (or windows equivalent)? Should I just igno开发者_运维技巧re the message? i.e. Are there explanations of how git handles the competing deletion & tracking mechanisms.

If you simply delete by using rm and then commit, that removal is not staged, so git just ignores the fact that that file is gone.

If you want git to recognize the removal of that file and update the repository accordingly, you have to git rm a file. In your case, git add -A . after deleting the old and unzipping the new will give you what you want. It adds all adds, deletes, and changes to the staging area.

With your current plan, you certainly have many files in the repository that you do not want. Your best bet is to start over, using the following strategy.

1. Create repo
2. Unzip files
3. git add -A .
4. git commit
5. Delete all files
6. Repeat from 2

Your guess it right--the recent commits contained copies of those deleted files.

Try git add -A ., it stage deletion as well.

If you want to know why..... because that's what staging area are best used: git have a concept of "stage area", which allow you commit only part of your modification -- this make splitting patches easier.