Git does not properly detect modification of certain files?

I've noticed that Git does not properly detect modified .out files (which are already in the index) generated by TI's Code Composer Studio (Eclipse). After compiling/building, calling git status shows .out files under changes to be committed (as deleted) and untracked files instead of in changes not staged for commit. Any idea what specifically causes certain files to end up like this?

This is not a problem with GIT. By design, this is how it works. I ran a test to double check but if:

1. A file file.out is part of the tree
2. Something/one runs git rm file.out. It has to be a git rm, if the deletion is not staged this won't reproduce.
3. You create a file of the same name. It will be listed as untracked.

This is standard GIT behavior. Staged changes are "almost" committed, and just like re-creating a file previously deleted in a different commit will be listed as new, so it will happen here. Note if the deletion is not staged, then what you expect as the right behavior will occur - git will know it is the same file.

To have git understand the files are the same, you need to run

4. git add file.out

so git sees the same file still exists in the stage area, and just lists a single modified staged to commit. The reason it works like this is to have an extra half committed layer you can still play around and reset to (like a checkpoint in a game).

As to why Composer does this I am not sure. I think the right behavior is staging all file changes, so I do not know why the new file is not added to the tree. If this is just a log output that is not part of the source consider adding *.out to .gitignore, though you have to make sure Composer is not adding it (and bypassing the ignore).