Am 25.07.24 um 12:37 schrieb Steve: > 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. 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
