Re: Bug: Git GUI "No differences detected"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux