I've had a look at all similar questions. However, I've double checked and something strange is definitely happening.
On one server (Solaris with Git 1.8.1) I cloned the Git repository then copied the .git folder into my existing live files. This worked perfectly, I could run
git status
then
git diff [filename]
to check any files that were different.
On another server (Solaris with Git 1.7.6) I'm doing exactly the same however
git diff [filename]
shows nothing, even if the contents of the file is definitely different. I have also tested adding a new file, committing it, and then editing. The same issue, git status
shows the file as changed, but git diff
shows nothing. If I download the changed file and run a diff locally then I get diff output.
I stumbled upon this problem again. But this time it occurred for a different reason. I had copied files into the repo to overwrite the previous versions. Now I can see the files are modified but diff doesn't return the diffs.
For example, I have a mainpage.xaml file.
In File Explorer I pasted a new mainpage.xaml file over the one in my current repo.
I did the work on another machine and just pasted the file here.
The file shows modified, but when I run git diff, it will not show the changes. It's probably because the fileinfo on the file has changed and git knows that it isn't really the same file. Interesting.
You can see that when I run diff on the file it shows nothing, just returns the prompt.
Line ending issue:
git config --global core.autocrlf true
unix2dos **
git add .
git status
I occassionally run into this issue that git status
shows I have files modified while git diff
shows nothing. This is most likely issue of line endings. I finally figured out how it always happen and share here to see if it can help others.
The reason I encounter this issue often is that I work on a Windows machine and interact with Git in WSL. Switching between linux and Windows setting can easily cause this end-of-line issue. Since line ending format used in OS differs:
\r\n
\n
When you install Git on your machine, it will ask you to choose line endings setting. Usually, the common practice is to use (commit) Linux-style line endings on your remote git repo and checkout Windows-style on your Windows machine. If you use default setting, this is what git do for you.
This means if you have a shell script myScript.sh
and bash script myScript.cmd
in your repo, the scripts both exist with Linux-style ending in your remote git repo, and both exist with Windows-style ending on your Windows machine.
I used to checkout shell script file and use dos2unix
to change the script line-ending in order to run the shell script in WSL. This is why I encounter the issue. Git keeps telling me my modification of line-ending has been changed and asks whether to commit the changes.
Use default line ending settings and if you change the line endings of some files (like use the dos2unix
or dos2unix
), drop the changings.
If line-endings changes already exist and you would like to get rid of it, try git add
them and the changes will go.
Running git add
sometimes helps.
Git status is showing changed files and git diff is showing nothing...
> git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: package.json
no changes added to commit (use "git add" and/or "git commit -a")
> git diff
>
...running git add resolves the inconsistency.
> git add
> git status
On branch master
nothing to commit, working directory clean
>
You did not really ask an actual question, but since this is a general use case I'm using quite often here's what I do. You may try this yourself and see if the error persists.
My assumption on your use case:
You have an existing directory containing files and directories and now want to convert it into a Git repository that is cloned from some place else without changing any data in your current directory.
There are really two ways.
Clone repo - mv .git
- git reset --hard
This method is what you did - to clone the existing repository into an empty directory, then move the .git
directory into the destination directory. To work without problems, this generally requires you then to run
git reset --hard
However, that would change the state of files in your current directory. You can try this on a full copy/rsync of your directory and study what changes. At least afterwards you should no longer see discrepancies between git log
and status
.
Init new repository - point to origin
The second is less disturbing: cd
into your destination, and start a new repository with
git init
Then you tell that new repository, that it has an ancestor some place else:
git remote add origin original_git_repo_path
Then safely
git fetch origin master
to copy over the data without changing your local files. Everything should be fine now.
I always recommend the second way for being less error-prone.
git diff -a
treats all file as text and it works for me.
As already noted in a previous answer, this situation may arise due to line-ending problems (CR/LF vs. LF). I solved this problem (under Git version 2.22.0) with this command:
git add --renormalize .
According to the manual:
--renormalize
Apply the "clean" process freshly to all tracked files to
forcibly add them again to the index. This is useful after
changing core.autocrlf configuration or the text attribute in
order to correct files added with wrong CRLF/LF line endings.
This option implies -u.
I used git svn
, and had this problem for one file. Using ls-tree
for each ancestor of the file, I noticed that one had 2 subfolders - Submit
and submit
. Since I was on Windows, they couldn't both be checked out, causing this issue.
The solution was to delete one of them directly from TortoiseSVN
Repo-browser
, then to run git svn fetch
followed by git reset --hard origin/trunk
.
I had this same problem described in the following way: If I typed
$ git diff
Git simply returned to the prompt with no error.
If I typed
$ git diff <filename>
Git simply returned to the prompt with no error.
Finally, by reading around I noticed that git diff
actually calls the mingw64\bin\diff.exe
to do the work.
Here's the deal. I'm running Windows and had installed another Bash utility and it changed my path so it no longer pointed to my mingw64\bin directory.
So if you type:
git diff
and it just returns to the prompt you may have this problem.
The actual diff.exe which is run by
git
is located in your mingw64\bin directory
Finally, to fix this, I actually copied my mingw64\bin
directory to the location Git was looking for it in. I tried it and it still didn't work.
Then, I closed my Git Bash window and opened it again went to my same repository that was failing and now it works.
For me, it had something to do with file permissions. Someone with Mac/Linux on my project seems to commit some files with non-default permissions which my Windows git client failed to reproduce. Solution for me was to tell git to ignore file permissions:
git config core.fileMode false
Other insight: How do I make Git ignore file mode (chmod) changes?
There are a few reasons why git status
might show a difference but git diff
might not.
The mode (permission bits) of the file changed-- for example, from 777 to 700.
The line feed style changed from CRLF (DOS) to LF (UNIX)
The easiest way to find out what happened is to run git format-patch HEAD^
and see what the generated patch says.
I added the file to the index:
git add file_name
and then ran:
git diff --cached file_name
You can see the description of git diff here.
If you need to undo your git add, then please see here: How to undo 'git add' before commit?
I had a similar problem: git diff
would show differences, but git diff <filename>
would not. It turned out that I set LESS
to a string including -F
(--quit-if-one-screen
). Removing that flag solved the problem.
I ran into this problem. My case was similar to the LESS
issue posted by rcwxok.
In my case, I set the PAGER
environment variable to PAGER='less -RSF'
.
However, unlike the previous answers, I didn't want to remove the -F
option, because I explicitly put it there hoping to prevent showing the diff in less
if it's shorter than a screenful.
To get the desired result, instead of removing -F
, I added -X
: PAGER='less -RSFX'
. This both solved the git diff
issue and in addition it prevents showing short diffs with less
.
I had an issue where hundreds of line endings were modified by some program and git diff
listed all source files as changed. After fixing the line endings, git status
still listed the files as modified.
I was able to fix this problem by adding all files to the index and then resetting the index.
git add -A
git reset
core.filemode
was set to false.
I've just run in a similar issue. git diff file
showed nothing because I added file to the Git index with some part of its name in uppercase: GeoJSONContainer.js
.
Afterwards, I've renamed it to GeoJsonContainer.js
and changes stopped being tracked. git diff GeoJsonContainer.js
was showing nothing. I had to remove the file from the index with a force flag, and add the file again:
git rm -f GeoJSONContainer.js
git add GeoJSONContainer.js
I suspect there is something wrong either with your Git installation or your repository.
Try running:
GIT_TRACE=2 git <command>
See if you get anything useful. If that doesn't help, just use strace and see what's going wrong:
strace git <command>
Source: Stackoverflow.com