Git is not detecting a file and is not in .gitignore

T

18

77

I have a file called "style.css" and git is not detecting it. It doesn't detect it if I delete it either, but it does detect if I change the name of the file. But I need it with that name. The file is not in the .gitignore file. This is driving me crazy!

I would appreciate some help.

Tournedos answered 14/3, 2012 at 18:5 Comment(12)

Git is not detected changes to the file in that you have already added and committed it? Or Git is not detected the file exists unless the name is changed? – Church 14/3, 2012 at 18:8

first try "git add ." and then check git status. if that doesn't work, navigate to that file directory and try "git add style.css" and do another git status... i think that will work – Cavan 14/3, 2012 at 18:11

The file is already added and commited in the past. But right now doesn't detect the changes, even when I delete de file – Tournedos 14/3, 2012 at 18:12

Have you checked some of the other gitignore places? #9436905 – Control 14/3, 2012 at 18:12

"git add ." and "git add style.css" didn't work, thats the first thing I tried – Tournedos 14/3, 2012 at 18:14

Are you by any chance using a case-insensitive file system? Perhaps OSX? – Jordain 14/3, 2012 at 18:15

Are there any entries in .gitignore in any of the parent folders which might match this file? – Paratrooper 14/3, 2012 at 18:24

@PaulBeckingham could something like this be a case-sensitivity problem? how? – Bakerman 14/3, 2012 at 18:48

I'm in Mac OS X. I have check all the .gitgnore files and I dont find it in any of them... :/ – Tournedos 14/3, 2012 at 19:9

Is it possible that you checked in the 'style.css' file using different casing? Such as 'Style.css'? The file system is case-insensitive, but git is not. I have seen this many times. – Jordain 14/3, 2012 at 23:59

FWIW I had this problem and solved it by deleting the offending file with "git rm". After committing the delete I was able to add back the modified file. – Graziano 15/7, 2013 at 21:3

For reference, this file was also used on my system: ~/.gitignore_global (MacOSX, git 2.11.0) – Kneepad 25/4, 2017 at 13:20

G

118

Use git check-ignore command to debug your gitignore file (exclude files).

In example:

$ git check-ignore -v config.php
.gitignore:2:src    config.php

The above output details about the matching pattern (if any) for each given pathname (including line).

So maybe your file extension is not ignored, but the whole directory.

The returned format is:

<source> <COLON> <linenum> <COLON> <pattern> <HT> <pathname>

Or use the following command to print your .gitignore in user and repo folder:

cat ~/.gitignore $(git rev-parse --show-toplevel)/.gitignore $(git rev-parse --show-toplevel)/.git/info/exclude

Alternatively use git add -f <path/file> which allows adding otherwise ignored files.

See: man gitignore, man git-check-ignore for more details.

Glisson answered 7/3, 2015 at 19:16 Comment(5)

git add -f . fixed it for me without cloning the repository. – Frons 13/11, 2016 at 11:16

This should be the accepted answer since it shows where the problem actually lies. – Columbic 11/1, 2017 at 15:5

This fixed things for me. I had a whole folder not showing nothing wrong or out of place anywhere. Running git add -f on one of the files brought everything back to life. Really gets frustrating GIT with its randoms at times. Thanks! – Ytterbium 10/11, 2017 at 1:23

Thanks. Just as I suspected, the path was set as a submodule. But it wasn't anywhere in configuration or can be removed with submodule deinit. Luckily I just created the repo, so I just removed the the .git folder and re-inited git. – Hairline 14/11, 2018 at 13:54

git add -f %relativepath% . eg: git add -f folder\file.xml to be more explicit – Harlene 27/5, 2019 at 10:12

M

19

Another note, probably a rare case but I had this problem. I moved some files that were already tied to a repo from one directory to another, copy/paste style.

Along with it came the .git folder, which prevented git from detecting the folder.

So my folder structure was this, with git not detecting Folder 2 even though the repo was set for Original Project 1:

--Original Project 1
    --.git
    --Folder 1
    --Folder 2
         --.git
         --Many other files/folders

Deleting the child .git folder solved my problem.

Monopoly answered 6/4, 2016 at 13:12 Comment(1)

This worked for me too, but it was worse in that my .git folder was hidden, which it typically isn't in Windows. I had to use a terminal to see and delete it. – Basement 24/3, 2022 at 23:48

P

12

The file could also be listed in .git/info/exclude, and there’s the option core.excludesfile to watch, too.

Platus answered 14/3, 2012 at 18:10 Comment(2)

this answer didn't really solve the question. the comment did. – Nairn 9/4, 2016 at 16:55

Facepalm moment: make sure your files are in the correct directory. Was working off a flash drive on a different machine and dropped the folder in the wrong spot when I got back to my main machine. Digging for the .git folder manually clued me in. :/ – Vaientina 10/1, 2017 at 0:54

P

8

Apart from the the gitignore and other places to check for ignore patterns, check if you had run git update-index --assume-unchanged or git update-index --skip-worktree. If so, unset them.

Make sure that there is not some weirdness in the repo or parent of the file under concern whereby it has a .git of its own.

Try doing a clone of your repo and see if you see the same in the cloned one. If so, try cloning onto a different machine / VM and check. That will give you some idea of what's going wrong where.

Powwow answered 14/3, 2012 at 19:46 Comment(2)

How would one check whether one had run either of those commands? – Ethiopia 22/5, 2014 at 18:11

Run git ls-files -v <file>. Any lowercase letter means --assume-unchanged was applied; S means --skip-worktree applied, and s means both applied. Try grepping the codebase for those options; I've worked on repos with scripts that run --assume-unchanged to prevent people from checking in updates to config files -- very annoying. – Lafleur 26/4, 2017 at 18:59

F

4

I had the same problem (components/dashboard/js-dev/training/index.js wasn't being tracked for some reason), so I did the following:

$ git check-ignore -v components/dashboard/js-dev/training/index.js
$ (gave me nothing)

$ git check-ignore -v components/dashboard/js-dev/training/
$ /Users/User/.config/git/ignore:23:    components/dashboard/js-dev/training/

Anyways, I found this to be quite weird, so then I took a look at this file, /Users/User/.config/git/ignore, and this is what it looked like:

(this is line 1)
# Automatically created by GitHub for Mac
# To make edits, delete these initial comments, or else your changes may be lost!

*.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon

# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

And it turns out that line 23 is in fact the one between .com.apple.timemachine.donotpresent and # Directories potentially created on remote AFP share, in other words, it was a completely empty line!

I tried removing all the extra newlines so my file looked like this:

# Automatically created by GitHub for Mac
# To make edits, delete these initial comments, or else your changes may be lost!
*.DS_Store
.AppleDouble
.LSOverride
# Icon must end with two \r
Icon
# Thumbnails
._*
# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent
# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

I run git status, and I notice that it's now picking up components/dashboard/js-dev/training/. I run git add components/dashboard/js-dev/training/, and all works fine again.

Hope this helps someone - this issue got me stuck for an unnecessarily long amount of time.

Firework answered 20/2, 2017 at 4:48 Comment(0)

E

2

I had a similar issue and solved it.

I was getting this error message when running the git add command:

The following paths are ignored by one of your .gitignore files:
<file>
Use -f if you really want to add them. 
fatal: no files added

So I tried to force Git to solve the issue for me by adding a -f to the git add command. This would normally force Git to adjust the .gitignore file and you will then be able to see the required change or problematic setting.

In my particular case there seemed to be some weird issue with the newline at the end of the .gitignore file. Here how Git fixed the problem:

-RemoteSystemsTempFiles
+RemoteSystemsTempFiles
\ No newline at end of file

Ezarra answered 30/7, 2014 at 10:42 Comment(1)

I tried this and it essentially resolved my problem however the .gitignore file was left unchanged. There is a blank line at the end of .gitignore; I wonder if that is the issue? – Installation 24/3, 2015 at 22:49

B

1

Extra note, I ran into this problem and found that changes to files weren't being added to commits. Nothing seemed to work, except Right clicking the project, and doing:

Team > Advanced > No assume unchanged

Brinna answered 28/7, 2014 at 15:0 Comment(0)

M

1

I also ran into this issue and it seems to be a problem with EGit plugin for Eclipse. Like @user1655478 said in previous comment, selecting the project in the projects view, performing a right click and selecting "Team > Advanced > No assume unchanged" fixed the problem for me.

Markland answered 6/8, 2014 at 10:14 Comment(0)

E

1

Another reason to this problem may be the .gitignore_global file. In my case, it was automatically produced by Sourcetree app while i was ignoring file. It was in my user path(/Users/user_name/.gitignore_global).

Extravagant answered 30/10, 2019 at 18:13 Comment(0)

U

0

If your project is a maven project, check if you changed the src file or the target file. That's what I did recently. With the file path reference being too long, I failed to notice the 'target' in the path. All good after 1 hr of agony.

Uriisa answered 10/12, 2015 at 4:5 Comment(0)

D

0

I encountered another cause for this. Probably very rare circumstances.

I copied my entire repository to another folder to work on it. Changes I made to a submodule just weren't being detected by git. Turned out that the .git file in the submodule folder contained an absolute file reference to the original copy. As soon as I corrected the file reference to point to my working copy all was well.

Devin answered 30/9, 2016 at 10:20 Comment(0)

S

0

some want to add an empty folder for some reasons If the content of the folder is empty, then there is no reason for git to mention it.

A convention says that you might want to add a file .keep to it. which could also any other file.

see here or here

Sachasachem answered 22/1, 2018 at 10:53 Comment(0)

B

0

this happened to me when I was working on a branch I had just created called 'am'. I got on another dev station and couldn't see the file I added to the branch. In order to see the file I ran the following command

git checkout am
git branch --set-upstream-to=origin/am
git pull

after the pull all the changes came down

Bobbee answered 27/2, 2019 at 21:8 Comment(0)

E

0

first check in your git repository to make sure that the file isn't there, sometimes capitalized letters can mess up a file being recognized but won't be recognized as a change, especially in a file extension like .JPG

(for some reason this happened to me although the file was saved the same as the others the extension was capitalized only on one and wouldn't appear on the site)

'if' this is the problem check 'show file name extensions' in relevant folder, rename file as something else with lower case extension, git add and commit and then rename it as originally wanted but keeping the lower case extension, because of the more obvious change it will be rewritten and not ignored

Ewold answered 22/3, 2019 at 3:42 Comment(0)

M

0

In my case I check my .gitignore_global, I found all my swift files ignored, I just removed the line *.swift and git recognized my ones.

Managerial answered 20/4, 2020 at 16:25 Comment(0)

R

0

This can happen as well when you change a file's casing (e.g. HelloWorld.txt > helloworld.txt). If this is the case for you, see How do I commit case-sensitive only filename changes in Git?

Refluent answered 12/2, 2023 at 15:26 Comment(0)

E

0

Maybe by mistake you have choosen th option Aassume Unchanged option

Please run this command

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

It worked for me after trying to solve this issue for 2 days

Eugine answered 5/12, 2023 at 21:38 Comment(0)

N

-2

Quitting the GitHub app worked for me.

Symptoms: My repo is on google file stream. I could only see modified files when running git status but the GitHub app showed all changes.

Necrophilism answered 18/2, 2018 at 16:52 Comment(0)

Recommended topics

Hot tags