I am trying to push my files to github using bash. They are already on there, and I am uploading a newer version with new lines and code, etc. But when I try git add and then git status it says:
On branch master
nothing to commit, working directory clean
And the file I am using was just modified.
I had a problem where once upon a time I set the git index to 'assume unchanged' on my file.
You can tell git to stop ignoring changes to the file with:
git update-index --no-assume-unchanged path/to/file
If that doesn't help a reset may be enough for other weird cases.
In practice I found removing the cached file and resetting it to work:
git rm --cached path/to/file
git reset path/to/file
The git rm --cached means to only remove the file from the index, and reset tells git to reload the git index from the last commit.
Sounds crazy, but sometimes you are not in the right repo even though you think you are. For example, you may have moved the parent directory, but forgot to switch repos in your text editor. Or vice versa: you're in the right repo in the text editor but the wrong repo in command line. In the first situation, you make your edits in the right file but it's not the same folder that's open in your command line, so it's actually the wrong file. In the second situation, you actually did edit the right file, but your command line git won't recognize the change because you're not in the correct directory on the command line.
Check your .gitignore file. You may find that the file, or extension of the file, or path to the file you are trying to work with matches an entry in .gitignore, which would explain why that file is being ignored (and not recognized as a changed file).
This turned out to be the case for me when I had a similar problem.
Like it was already discussed, the files were probably flagged with "assume-unchanged", which basicly tells git that you will not modify the files, so it doesnt need to track changes with them. However this may be affecting multiple files, and if its a large workspace you might not want to check them all one by one. In that case you can try: git update-index --really-refresh
according to the docs:
Like --refresh, but checks stat information unconditionally, without regard to the "assume unchanged" setting.
It will basicly force git to track changes of all files regardless of the "assume-unchanged" flags.
Following commands worked for me
rm .git/index
git reset
well we don't have enough to answer this question so I will give you several guesses:
1) you stashed your changes, to fix type: git stash pop
2) you had changes and you committed them, you should be able to see your commit in git log
3) you had changes did some sort of git reset --hard or other, your changes may be there in the reflog, type git reflog --all followed by checking out or cherry-picking the ref if you ever do find it.
4) you have checked out the same repo several times, and you are in the wrong one.
I had some git submodule misconfiguration. I went to repo's root and issued these commands on the directories that had .git folders previously:
git rm --cached sub/directory/path -f
Then the directories appeared in git status.
You may want to make a copy of your repo before trying this just in case.
We've had this happen on Windows when changing files by transferring differences via the WinMerge tool. Apparently WinMerge (at least the way it's configured on my computer) sometimes doesn't update the timestamps of files it changes.
On Windows, git status, uses, among other things, a file's time stamp and changes in the file's size to determine whether or not a file has changed. So since the time stamp wasn't updated, it only had the file size to go by. Unfortunately the file in question was a simple version file where the content changed from 7.1.2 to 7.2.0. In other words, the file size also remained unchanged. Other files that were also changed by WinMerge and didn't have their time stamps updated but had a different size after the change were detected by git status just fine.
Had a funky thing like this happening. Eclipse Kepler's git plugin was automatically marking all my project folders as ignored in the .gitignore folder.
When I would got to commit on the Team menu, they would all set back to ignored. As far as I can tell, this was because I'd set them as derived in the parent project. Unmarking them as dervied fixed this. I'd never seen this before on Indigo. Hope it helps someon.
TL;DR; Are you even on the correct repository?
My story is bit funny but I thought it can happen with someone who might be having a similar scenario so sharing it here.
Actually on my machine, I had two separate git repositories repo1 and repo2 configured in the same root directory named source. These two repositories are essentially the repositories of two products I work off and on in my company. Now the thing is that as a standard guideline, the directory structure of source code of all the products is exactly the same in my company.
So without realizing I modified an exactly same named file in repo2 which I was supposed to change in repo1. So, I just kept running command git status on repo1 and it kept giving the same message
On branch master
nothing to commit, working directory clean
for half an hour. Then colleague of mine observed it as independent pair of eyes and brought this thing to my notice that I was in wrong but very similar looking repository. The moment I switched to repo1 Git started noticing the changed files.
Not so common case. But you never know!
Did you move the directory out from under your shell? This can happen if you restored your project from a backup. To fix this, just cd out and back in:
cd ../
cd -
I had a similar issue while using Sublime Text-3. After making new changes in the code and saving it, when I tried the git add ./status commands the response was "branch already-up to date". I figured out, regardless saving the updates in the text editor, the file was actually unchanged. Opening file in other editor and saving the changes worked for me.
I had the same problem. Turns out I had two copies of the project and my terminal was in the wrong project folder!
When you edit a file in Visual Studio it gets listed in git changes instantly even if the file is not saved. So all you need to do is just to save the file manually (Ctrl+S for the currently displayed file or Ctrl+Shift+S for all project files) and git bash will pick them up.
It happend to me as well, I tried the above mentioned methods and nothing helped. Then the solution was to change the file via terminal, not GUI. I do not know why this worked but worked. After I edited the file via nano from terminal git recognized it as changed and i was able to add it and commit.
I had the same issue. And the files that I needed to be committed were never declared in the .gitignore file as well.
In my case adding the files forcefully using the -f flag elevated to staging and fixed the issue.
git add -f <path to file>
git update-index --really-refresh
you can try this command, it will update indexes in your folder.
I had the same problem after Google Drive desktop synced my project files, Git was not detecting changes.
What I found is that this git rm --cached -r . with sudo credentials work. Then don't do git reset, this only resets git status and set everything back to the point in time of the issue.
So for Linux and mac, this works well:
`sudo git rm --cached -r .`
In general with this issue, first check that you're editing the file you think you are! I had this problem when I was editing a transpiled JavaScript file instead of the source file (the transpiled version wasn't under source control).
My Git client (Gitg) caused this issue for me. Normal commands that I would usually run weren't working. Even touching every file in the project didn't work.
I found a way to fix it and I'm still not sure what caused it. Copy your project directory. The missing files will show up in the copied directory's git status. Renaming might do the same thing.
Make sure not to create symlinks (ln -s source dest) from inside of Git Bash for Windows.
It does NOT make symlinks, but does a DEEP copy of the source to the dest
I experienced same behavior as OP on a MINGW64 terminal from Git Bash for Windows (version 2.16.2) to realize that my 'edited' changes actually were in the original directory, and my git bash commands were from within a deep copy that had remained unchanged.
Ran into the issue, but it was only two directories and unknown to me was that both those directories ended up being configured as git submodules. How that happened I have no clue, but the process was to follow some of the instructions on this link, but NOT remove the directory (as he does at the end) but rather do git add path/to/dir
If you are using VSCode you have to save the changes first before git can recognize them.
Press:
Ctrl + Shift + S for Window
Command + S for Mac
now git status again
What kind of file do you tried to upload? Now I just spend almost an hour to upload my css modification. But this css compiled from a styl file therefore git just ignored it. When I changed the styl source then everything worked.
Hope it helps.
Sometimes depend and by git version and if you forget to do git add ..
To check about your change on repository use always git status that show all untracked and changed files. Because git diff show only added files.
i have the same problem here VS2015 didn't recognize my js files changes, removing remotes from repository settings and then re-adding the remote URL path solved my problem.
If you are using VSCode and switched to a new machine, you may have Autosave off, so even if you make changes to a file, git won't recognize them.
This solved my issue
The following worked for me:
git mv tesfile.js TestFile.js
for more details check out: https://stackoverflow.com/a/16071375/11677643
This happened to me when all changes were in a new directory. I added the first file
git add newdirectory/new.file
and then git status showed the other files in the directory as expected.
Try renaming the File and git will recognize a new change to add the file.
For example , if the File path is Product/index.tsx then you can just rename the path to : ProductItem/index.tsx.
This worked! after attempting all the suggested solutions above.
For future readers: I had an interesting case where we tried to copy a whole folder into a git repository, not realizing that we also copied the .git folder with it.
Since the index of the copied .git folder contains the contents of the copied folder, git thought that no changes were being made.
The Solution in my case was to create a new branch and only copy the folder without the .git folder.
Rebooting windows was the only thing that worked for me to resolve this issue; whereas closing the powershell window/visual studio had no effect.
I watched in Visual Studio, while editing, VS would visuall show it changed, great. But when I saved, VS, nor the commandline git status would show it to be changed.
Again, I shut everything down and rebooted.
I was having the same problem. In my case, autosave was turned off in my text editor and the changes were therefore not being picked up on my command line. I turned on autosave, and it works okay now.
We tried the above solutions, but unfortunately it did not worked in our end.
Later I found what causing the problem is that my sub-directory has its own .ssh/ directory.
So the working solution in our end,
(1) - is to remove the .git/ directory in the sub-directory
/.git
/frontend
/.git <-----------delete this
/backend
/.git <-----------delete this
(2) - Remove cached
git rm --cached .
(3) - Stage the changes
git add .
Check your excludefile in the .git folder. I had the same issue and got some entry in the excludefile (or excludesfile) that prevented git to work correctly
I had this issue. Mine wasn't working because I was putting my files in the .git folder inside my project.
try to use git add *
then git commit
