git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Bug: Git GUI "No differences detected"
@ 2024-07-25 10:37 Steve
  2024-07-30 19:27 ` Johannes Sixt
  0 siblings, 1 reply; 4+ messages in thread
From: Steve @ 2024-07-25 10:37 UTC (permalink / raw)
  To: git

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Bug: Git GUI "No differences detected"
  2024-07-25 10:37 Bug: Git GUI "No differences detected" Steve
@ 2024-07-30 19:27 ` Johannes Sixt
  2024-07-31 11:01   ` Steve
  2024-12-21 13:05   ` Johannes Sixt
  0 siblings, 2 replies; 4+ messages in thread
From: Johannes Sixt @ 2024-07-30 19:27 UTC (permalink / raw)
  To: Steve; +Cc: git

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Bug: Git GUI "No differences detected"
  2024-07-30 19:27 ` Johannes Sixt
@ 2024-07-31 11:01   ` Steve
  2024-12-21 13:05   ` Johannes Sixt
  1 sibling, 0 replies; 4+ messages in thread
From: Steve @ 2024-07-31 11:01 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: git

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 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Bug: Git GUI "No differences detected"
  2024-07-30 19:27 ` Johannes Sixt
  2024-07-31 11:01   ` Steve
@ 2024-12-21 13:05   ` Johannes Sixt
  1 sibling, 0 replies; 4+ messages in thread
From: Johannes Sixt @ 2024-12-21 13:05 UTC (permalink / raw)
  To: Steve; +Cc: git

Am 30.07.24 um 21:27 schrieb Johannes Sixt:
> 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.

> 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.

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(-)

diff --git a/git-gui.sh b/git-gui.sh
index 8fe7538..887d6d5 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1357,7 +1357,6 @@ set current_diff_path {}
 set is_3way_diff 0
 set is_submodule_diff 0
 set is_conflict_diff 0
-set diff_empty_count 0
 set last_revert {}
 set last_revert_enc {}
 
@@ -3594,6 +3593,8 @@ $ui_diff tag configure clr1 -font font_diffbold
 $ui_diff tag configure clr4 -underline 1
 
 $ui_diff tag conf d_info -foreground blue -font font_diffbold
+$ui_diff tag conf d_rescan -foreground blue -underline 1 -font font_diffbold
+$ui_diff tag bind d_rescan <Button-1> { clear_diff; rescan ui_ready 0 }
 
 $ui_diff tag conf d_cr -elide true
 $ui_diff tag conf d_@ -font font_diffbold
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 871ad48..d657bfe 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -63,28 +63,17 @@ proc force_diff_encoding {enc} {
 }
 
 proc handle_empty_diff {} {
-	global current_diff_path file_states file_lists
-	global diff_empty_count
+	global current_diff_path file_states
+	global ui_diff
 
 	set path $current_diff_path
 	set s $file_states($path)
 	if {[lindex $s 0] ne {_M} || [has_textconv $path]} return
 
-	# Prevent infinite rescan loops
-	incr diff_empty_count
-	if {$diff_empty_count > 1} return
-
-	info_popup [mc "No differences detected.
-
-%s has no changes.
-
-The modification date of this file was updated by another application, but the content within the file was not changed.
-
-A rescan will be automatically started to find other files which may have the same state." [short_path $path]]
-
-	clear_diff
-	display_file $path __
-	rescan ui_ready 0
+	$ui_diff conf -state normal
+	$ui_diff insert end [mc "* No differences detected; stage the file to de-list it from Unstaged Changes.\n"] d_info
+	$ui_diff insert end [mc "* Click to find other files that may have the same state.\n"] d_rescan
+	$ui_diff conf -state disabled
 }
 
 proc show_diff {path w {lno {}} {scroll_pos {}} {callback {}}} {
@@ -387,7 +376,6 @@ proc read_diff {fd conflict_size cont_info} {
 	global ui_diff diff_active is_submodule_diff
 	global is_3way_diff is_conflict_diff current_diff_header
 	global current_diff_queue
-	global diff_empty_count
 
 	$ui_diff conf -state normal
 	while {[gets $fd line] >= 0} {
@@ -559,8 +547,6 @@ proc read_diff {fd conflict_size cont_info} {
 
 		if {[$ui_diff index end] eq {2.0}} {
 			handle_empty_diff
-		} else {
-			set diff_empty_count 0
 		}
 
 		set callback [lindex $cont_info 1]
-- 
2.48.0.rc0.201.g092d4fe2cc


^ permalink raw reply related	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-12-21 13:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-25 10:37 Bug: Git GUI "No differences detected" Steve
2024-07-30 19:27 ` Johannes Sixt
2024-07-31 11:01   ` Steve
2024-12-21 13:05   ` Johannes Sixt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).