Bug: Git GUI "No differences detected"

Hi, I want to ask you about a bug that Git has had for years. It's tracked on pages like https://stackoverflow.com/questions/57556917/git-gui-no-diffferences-detected but I still haven't been able to find a solution to prevent this from occurring.

Problem: Git GUI shows a "No differences detected" popup when clicking on a file, and it returns back to the same state after closing the popup. When I do `git status`, the file is listed there, but `git diff` (with any line-ending-related switches inspired by stackoverflow) doesn't show anything for the file.

Cause: I assume it's typically due to LF/CRLF changes.

Workaround: Manually add the file, which makes the diff disappear.

Complaint: It's extremely annoying to click so many times on GUI for every such file. Files have to be frequently added just to satisfy the status check, really disrupting your workflow when preparing commits and reviewing diffs one by one.

Attempted settings: I tried all the autocrlf options, and even fileMode (though I'm on Windows); nothing helps to remove the file from status...

Reasons triggering the symptom: I have some application that periodically modifies tracked files in some way, causing this issue to regularly re-appear for the same set of files. Over the years, I had it happen from various sources, it's one of the issues that follows you the entire life...

Request: It needs to be recognized as a frequently occurring bug that doesn't have a permanent solution yet. It should be fixed either on the Git GUI side by automatically hiding these files (or at least hiding the annoying pop-up), or the git status itself could recognize that the file has in fact not changed. If there is any actual change in the line endings, its diff should be displayed, because that would be definitely an actual modification to the file, which we may want to review and push upstream. The current design of hiding CR/LF changes from a user is flawed anyway.

Thanks, I'm really hoping this can be officially tracked and reported on; a reliance on StackOverflow articles as an issue tracker is insufficient and hides our sentiment of how many hours of productivity we're wasting on it.

Am 25.07.24 um 12:37 schrieb Steve:

Back in 2006, the only case where a file could be listed as modified, but then not have any changes was when the timestamp (and perhaps other stat information) was modified, but not the content. Such false positives can be rectified by running git update-index --refresh, therefore, Git GUI does so by default. For this reason, users generally do not see false positives in the unstaged files list.

However, in large repositories git update-index --refresh can be so expensive that it becomes annoying. For this reason, the option "trust file modification times" was invented that, when enabled, skips this expensive step. On the flip side, there can now be files listed as modified that are actually not. As a work-around, the popup message was invented to notify the user that a --refresh step is performed to remove all false positives.

This worked sufficiently well. Until core.autocrlf was invented in 2007.

Enabling this option introduced a new case that can trigger false positives. But this time, git update-index --refresh does *not* clear the files that are falsly marked as modified. And we end up in the loop that you described and that requires the file to be staged (git add) to be recognized as unmodified.

I suggest the following changes to Git GUI:

1. Remove the popup.

2. Write a message in the diff pane when the diff is empty saying that
no differences where found and that the file should be staged to remove
it from the unstaged file list.

3. If the option "trust file modification times" is set, extend the
message with an hyperlink that, when clicked, runs the --refresh stage,
i.e., the action that currently happens when the popup is dismissed.

Step 2 effectively makes the workaround the official solution. Would that work for you?

-- Hannes

Change #2 would still require us to manually stage dozens of files each time this happens, so I'm hoping a root cause solution can be found to prevent the changed file from appearing in status at all. But yeah, removing the popup would at least reduce the number of clicks by half.

ut 30. 7. 2024 o 21:27 Johannes Sixt <j6t@kdbg.org> napísal(a):

Am 30.07.24 um 21:27 schrieb Johannes Sixt:

Just these days I stumbled over a similar case of 'no differences detect' while I was operating a Git GUI that has the below patch, and it worked very well for me. I'll include it in the next release.

---- 8< ----
From: Johannes Sixt <j6t@kdbg.org>
Subject: [PATCH] git-gui: Remove forced rescan of stat-dirty files.

It is possible that stat information of tracked files is modified without actually modifying the content. Plumbing commands would detect such files as modified, so that Git GUI runs `git update-info --refresh` in order to synchronize the cached stat info with the reality. However, this can be an expensive operation in large repositories. As remediation, e534f3a88676 (git-gui: Allow the user to disable update-index --refresh during rescan, 2006-11-07) introduced an option to skip the expensive part.

The option was named "trust file modification timestamp". But the catch is that sometimes file timestamps can't be trusted. In this case, a file would remain listed in Unstaged Changes although there are no changes. So 16403d0b1f9d (git-gui: Refresh a file if it has an empty diff, 2006-11-11) introduced a popup message informing the user about the situation and then removed the file from the Unstaged Changes list.

Now users had to click away the message box for every file that was stat-dirty. Under the assumption that a file in such a state is not the only one, 124355d32c06 (git-gui: Always start a rescan on an empty diff, 2007-01-22) introduced a forced (potentially expensive) refresh that would de-list all stat-dirty files after the first notification was dismissed.

Along came 6c510bee2013 (Lazy man's auto-CRLF, 2007-02-13) in Git. It introduced a new case where a file in the worktree can have no essential differences to the staged version, but still be detected as modified by plumbing commands. This time, however, the index cannot be synchronized fully by `git update-index --refresh`, so that the file remains listed in Unstaged Changes until it is staged manually.

Needless to say that the message box now becomes an annoyance, because it must be dismissed every time an affected file is selected, and the file remains listed nevertheless.

Remove the message box. Write the notice that no differences were found in the diff panel instead. Also include a link that, when clicked, initiates the rescan. With this scheme, the rescan does not happen automatically anymore, but requires an additional click. (This is now two clicks in total for users who encounter stat-dirty files after enabling the "trust file modification timestamps" option.) However, users whom the rescan does not help (autocrlf-related dirty files) save half the clicks because there is no message box to dismiss.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
 git-gui.sh   |  3 ++-
 lib/diff.tcl | 26 ++++++--------------------
 2 files changed, 8 insertions(+), 21 deletions(-)