Why is git ignoring my changed file?

问题:

I make an arbitrary change to a file within my git working directory.

git status does not recognized that the file has changed.

git add /path/to/file has no effect.

git add -f /path/to/file has no effect.

git status /path/to/file shows the file as in the 'changes to be committed' bucket.

I removed my .gitignore file, just to be sure. No change to any of the above behaviors.

I have done git reset --hard, re-made my change. No change to any of the above behaviors.

What could be going on here?

回答1:

There are two general reasons why Git will ignore a file: gitignore and submodules.

To be more specific, the following conditions will cause Git to ignore a file when 'git add' is invoked:

1. The file matches a pattern in $GIT_DIR/exclude.
2. The file matches a pattern in a .gitignore file inside the repo.
3. The file matches a pattern in a user-specific .gitignore file (specified by 'git config --global core.excludesfile').
4. The file is part of a submodule.

More info can be found in another SO question:

Unable to track files within Git submodules

回答2:

Also make sure that you have not manually updated the index to assume that the changed file(s) are unchanged like so:

git update-index --assume-unchanged path/to/file

As dumb as it sounds I did that, then a few days later made changes to the file and could not figure out why git was not tracking it. I tried all of the above suggestions, and kept pulling my hair out b/c the changed file was not listed in any .gitignore or exclude files.

If you've told git to assume the file is unchanged, you will have to:

git update-index --no-assume-unchanged path/to/file

or just re-clone the repo like I ended up doing before I remembered what I had done...

回答3:

Turns out I added skip-worktree on my file ^[1]

git update-index --skip-worktree path/to/file

and forgot. You can undo this with:

git update-index --no-skip-worktree path/to/file

ls-files with -v revealed the status of the file in my case:

git ls-files -v | grep path/to/file
S path/to/file

The letters git ls-files -v will prefix with are and mean:

# H: cachead
# S: skip-worktree
# M: unmerged
# R: removed/deleted
# C: modified/changed
# K: to be killed
# ?: other
# lowercase letter: assume-unchanged

To identify your issue

Is the file ignored by git?

git check-ignore * **/* | grep path/to/file
git ls-files --exclude-standard --ignore

If the file is listed, there is an ignore rule somewhere that is excluding it.^[2] [3] Find it in one of these files:

less .gitignore
less ~/.gitignore
less %USERPROFILE%\.gitignore # <- Probably the same file as the above one
less $( git config --global core.excludesfile )
less $( git config --system core.excludesfile )
less ${GIT_DIR:-.git}/exclude

Is the file flagged assume-unchanged

git ls-files -v | grep path/to/file

If the file is prefixed with a lower case letter, it is flagged with assume-unchanged. Fix it with:

git update-index --no-assume-unchanged path/to/file

Is the file flagged skip-worktree

git ls-files -v | grep path/to/file

If the file is prefixed with S, it is flagged with skip-worktree. Fix it with:

git update-index --no-skip-worktree path/to/file

回答4:

Check using

$ git ls-files --exclude-standard --ignore

if the file is truly not excluded (there are other exclude files than only .gitignore).

回答5:

You check your global git ignore file?

git config --global --get-all core.excludesfile
git config --system --get-all core.excludesfile

If either of those return a file as their value, look in that file.

回答6:

if your file is in the 'Changes to be committed' bucket then git already recognized the change and is going to commit it! Its in the index already. Otherwise it would be in the 'Changed but not updated' bucket.

:)

Hope this helps/

回答7:

Are you sure that your file is not excluded by some of the .gitignore files in parent directories?

回答8:

After you did git add, did you do a commit so it's actually in the repo and can be compared to the (changed) working copy?

回答9:

Check each parent directory from the file in question to the project root for .gitignore files.

Some projects use several .gitignore files, each in its own directory, instead of a single .gitignore in the root.