Git does not properly detect modification of certain files?

Question

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?

Answer 1

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).

Answer 2

A file's status is "deleted" if it exists in the current commit but not in the index.

A file is untracked if it exists in the work-tree but is not in the index.

In this case, both are true: the file is in the current commit (frozen there forever, along with all the other frozen-into-the-commit files), not in the index (because someone or something removed it from the index), and is in the work-tree. Given your description in this comment, the IDE may have either run git rm to remove the file from both the index and work-tree, or may have run the equivalent of git add -u after deleting the file from the work-tree but before re-creating the file in the work-tree.

(The git add command, noticing that the file is missing from the work-tree, will remove the file from the index. A subsequent git add, run when the file is in the work-tree, will copy it into the index, but you'll need a variant of git add that adds a file that is not already present in the index.)