[git] 'git status' shows changed files, but 'git diff' doesn't

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.

This question is related to git diff

The answer is


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.
git shows modified

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.

git diff shows nothing

You can see that when I run diff on the file it shows nothing, just returns the prompt.


TL;DR

Line ending issue:

  1. Change autocrlf setting to default true. I.e., checkout Windows-style line endings on Windows and commit Linux-style line endings on remote git repo:
    git config --global core.autocrlf true
    
  2. On a Windows mahcine, change all files in the repo to Windows-style:
    unix2dos **
    
  3. Git add all modified files and modified files will go:
    git add .
    git status
    

Background

  • Platform: Windows, WSL

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.

Root Cause

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:

  • Windows: \r\n
  • OSX / Linux: \n

Common Practice

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. enter image description here

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.

Solution

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.


Short Answer

Running git add sometimes helps.

Example

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>