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.
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.
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 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>
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 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.
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.
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.
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
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.
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.
I had a similar issue when I created a patch file in server with vi editor. It seems the issue was with spacing. When I pushed the patch from local, deployment was proper.
I had this issue. Mine wasn't working because I was putting my files in the .git folder inside my project.
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.
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.
try to use git add *
then git commit
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.
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.
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.
I had the same problem. Turns out I had two copies of the project and my terminal was in the wrong project folder!
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.
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!
In my case, doing a git reset --hard deleted files & left some empty folders. After inspecting the content, I noticed the directories were empty.
However git ignores empty folders. (Correction, git ignores all directories as it tracks content, empty folders are not content.)
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 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.
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.
Source: Stackoverflow.com