You update a module that deletes a bunch of files. An hour later, you decide to combine two files into one, and delete the other file. At the end of the day, you decide to do a git commit.
You run git status and a bunch of deleted files show up. Darn, well I'll do a "git add ." and try to commit. The deleted files don't go away, and they don't stage to commit.
How do you get these deleted files out of your working directory, so when you run "git status," you get that blessed "nothing to commit (working directory clean)" message, we all know and love?
First, so we're on the same page, let's do some quick definitions.
The git "directory" (.git) is where git stores all the information about your project, all the history, all the commits, and all the meta information about your repository, and what files and folders are included in that repository. There is only one ".git directory" per repository.
Your "working directory" is where Git keeps track of all the content changes to your files and folder as your working: all your new files, deleted files, and modified files, since your last commit. It is created when you create a branch, and changes as you do commits. Each branch has its own "working directory" which can be, but doesn't have to be, different for each branch.
The git "index" is where you keep track of changes you want to make to your next commit. When you do a "git add," you stage the files in your working directory to your "index" in preparation to commit.
If you "git add" all the file changes in your working directory to the index, the working directory is clean. When you commit, git makes the commit match the index, and clears the index, and we get the "nothing to commit (working directory clean)" message when asking for a git status.
The problem with removing files or folders, as your working, is that these changes are recorded in your working directory, but a "git add ." cannot put the deleted files in the "index," because they don't exist anymore, you deleted them. But they still show up in your working directory, when you run "git status," because they have not been cleared out of your git "working directory." Seems like a cache 22. You can't add them to your index to commit the deletion, and you can't get the deleted files out of your "working directory," since they are different from your last commit. Are we doomed to have a long list of deleted files? You know better.
First, let's use git add like we normally do with a switch.
"git add -u" This is the same as "git add --update"
The -u says look at the index, and only add files from your working directory that are in the index. Any files with modified content in the index will be updated, and any files that have been removed in the working directory, will be put in the index for removal in the next commit.
This is what we want, when we do a commit the deleted files go away, but there's a catch. The -u will work, but new files in the working directory will not be added, since this is an update. You still have to run "git add ." to get the new files. Use -u when you don't want to commit new changes yet, but want to move deleted files to your index for the next commit.
Let's simplify. Let's use:
"git add -A" This is the same as using "git add --all"
This is like "git add -u," however it matches files in your working directory, and your index. That means that it will add new files, as well as updating modified content in your index, and remove files that are no longer in the working directory. Note, there is no "git add -a" Linux is case sensitive, the "a" doesn't work, the "A" does.
This is the best of both worlds and the recommended way to clear those deletes from your working directory.
One last thought, if you use "git rm <file name>" when you remove a file, this removes the file from both your working directory, and updates your index, ready for commit.
Git rm is not always possible when your in the middle of developing, it's just not convenient. "git add -A" is what you want.