Question

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 ignore the message? i.e. Are there explanations of how git handles the competing deletion & tracking mechanisms.

Answer 1

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.