11

I have a repository in Git, where a large number of files are flagged as being edited by Git Gui, a dialog comes up when I click on one of them containing:

    "No differences detected.

     filename.h has no changes.

     The modification date of this file was updated by another
     application, but the context within the file has not changed.

     A rescan will be automatically started to find other files which
     may have the stame state."

If I click on the Ok button the application rescans and displays exactly the same results which presents and endless loop because any file with this condition presents the same dialog.

Is there any way I can remove these automatically from the scan by ignoring white space ?

SPlatten
  • 5,334
  • 11
  • 57
  • 128

2 Answers2

7

Check first if your git config --global core.autocrlf is set to false.

If not (or if empty), set it to false, clone again your Git repository, and check if the Git GUI persists in its assessment.

The message itself comes from "git-gui/lib/diff.tcl#handle_empty_diff", whose blame view shows 10+ years-old code.

Ironically, there is a commit named "git-gui: Avoid an infinite rescan loop in handle_empty_diff." (commit 584fa9c)

If the index update machinery and git diff happen to disagree on whether a particular file is modified, it may cause git-gui to enter an infinite index rescan loop, where an empty diff starts a rescan, which finds the same set of files modified, and tries to display the diff for the first one, which happens to be the empty one.
A current example of a possible disagreement point is the autocrlf filter.

This patch breaks the loop by using a global counter to track the auto-rescans. The variable is reset whenever a non-empty diff is displayed.

Another suggested approach, which is based on giving the --exit-code argument to git diff, cannot be used, because diff-files seems to trust the timestamps in the index, and returns a non-zero code even if the file is actually unchanged, which essentially defeats the purpose of the auto-rescan logic.

Try using this: git add --renormalize -- :/

Tawnos
  • 1,877
  • 1
  • 17
  • 26
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • It is set to false. – SPlatten Aug 20 '19 at 06:39
  • Is this file opened by another application? – VonC Aug 20 '19 at 06:41
  • No, I was just using Git GUI, its so annoying, it brings up lots of files in the Unstaged Changes list, and when these are clicked on I get the original message as posted and then it rescans. – SPlatten Aug 20 '19 at 06:43
  • @SPlatten What version of Git are you using? On which OS? I have edited my answer. – VonC Aug 20 '19 at 11:07
  • git version 2.22.0.windows.1 on Microsoft Windows [Version 10.0.16299.1268] – SPlatten Aug 20 '19 at 12:35
  • @SPlatten Try Git 2.23 (https://github.com/git-for-windows/git/releases/tag/v2.23.0.windows.1) and `git add --renormalize -- :/` – VonC Aug 20 '19 at 12:37
  • its not really my decision to make, thank you anyway – SPlatten Aug 20 '19 at 12:47
  • @SPlatten It is just an archive un uncompress ([`PortableGit-2.23.0-64-bit.7z.exe`](https://github.com/git-for-windows/git/releases/download/v2.23.0.windows.1/PortableGit-2.23.0-64-bit.7z.exe)), you have full control. Adapt your `%PATH%` (in your current CMD session) to a simplified one, just for testing. No installation, no registry modification, no privilege elevation required. – VonC Aug 20 '19 at 13:01
1

VonC's answer above fixed this very annoying bug for me. It should be the accepted solution.

One problem was I copied and pasted the "git add --renormalize -- :/", which ended up with his period at the end of the sentence, like this: "git add --renormalize -- :/." I came back after an hour to this answer and realized what I had done.

It was my fault entirely, as his code marker was obvious in hindsight.

Ferd
  • 197
  • 1
  • 4