guberm / tortoisegit

Automatically exported from code.google.com/p/tortoisegit
0 stars 0 forks source link

Working shell icons overlay selection toggles #1922

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
TortoiseGit is at least half about displaying shell overlay icons telling me 
the current state of files and directories. Without it, it's practically 
useless because I'm blind.

Recently, after upgrading to TortoiseGit 1.8.5 and Git 1.8.3, I find that I 
regularly need to switch the Status Cache setting between "Default" and "Shell 
Extended" for it to display the correct and current file status. As soon as I 
notice that the overlays are outdated, I just go to the settings, select 
whichever other option, and it's good again. As a cross-check, switching it 
back immediately leads to the wrong icons again. Does the meaning of those 
options somehow depend on the current week, or day of week?

What version of TortoiseGit and msysgit are you using? On
what operating system?
TortoiseGit 1.8.5
Git 1.8.3
Windows 7 x64

Original issue reported on code.google.com by yves.goe...@gmail.com on 2 Oct 2013 at 10:51

GoogleCodeExporter commented 9 years ago
My Temporary Way:

1. Use "Git Commit..."
2. Wait for showing Commit dialog
3. Push ESC key to cancel the dialog
These steps will force icons refresh.

Test on XPP x86 and Win7 x64
TGit 1.8.5
msysgit 1.8.3
(Set Icon Overlay Status cache to "Default", check the attached file)

Hi Project Members:

Is it possible to provide "Force Overlay Refresh" function?
Just like that I use Commit dialog to do this.

Thanks~

Original comment by yuelinho...@gmail.com on 3 Oct 2013 at 6:14

Attachments:

GoogleCodeExporter commented 9 years ago
defect image file 1 (DefectOverlay-SetToDefault.PNG):

Testing Steps:
0. use "Default" Status cache
1. modify Readme.txt
2. modify Readme.txt back to origin content  (not use revert function)
3. overlay of Readme.txt is ok, but overlay of "Test" folder is wrong.

Original comment by yuelinho...@gmail.com on 3 Oct 2013 at 6:33

Attachments:

GoogleCodeExporter commented 9 years ago
I checked the help document at section 3.35.2

Set Status cache to Default, it says:
"In the current implementation it doesn't check the contents of the files, it 
just checks the last modification time against the time stored in the git index 
file".

Therefor, the "Test" folder shows red icon overlay.

Sorry. Just forget my post(#2).

Original comment by yuelinho...@gmail.com on 17 Oct 2013 at 6:03

GoogleCodeExporter commented 9 years ago
To force a refresh create and delete a file in the repository root. We're 
investigating this issue, maybe it's caused by lost signals.

Original comment by sstrickr...@googlemail.com on 3 Nov 2013 at 11:40

GoogleCodeExporter commented 9 years ago
Btw. since TortoiseGit 1.7.13 TGitCache also checks file contents -> docs 
updated.

Original comment by sstrickr...@googlemail.com on 3 Nov 2013 at 11:41

GoogleCodeExporter commented 9 years ago
Thanks for TortoiseGit - even tho I mostly use bash, I migrated from tsvn and 
so I really appreciate tgit, I also use thg!

TortoiseGit 1.8.7.0 (C:\Program Files\TortoiseGit\bin\)
git version 1.8.5.2.msysgit.0 (C:\Program Files (x86)\Git\bin)
OS: Windows 7 x64

I consistently have this issue as well:

(1) that the overlay icon shows status as modified, but there are no modified 
files or directories in the lowest directory of the tree.
(2) that msysgit bash shows the repo as unmodified
(3) that git gc occasionally fixes the issue, but not consistently
(4) that creating an untracked/non-ignored empty directory in the repo using MS 
Explorer can cause the issue
(5) however repeating (4) within msysgit-bash does **not** cause the issue

* I haven't tried to change the status cache from default to shell, but will 
give it a try
* I really like the idea of forcing a redraw of the icons similar to TortoiseHg 
if it works - but it would be useless if it doesn't solve the root cause

Thanks!

Original comment by bwanama...@gmail.com on 26 Feb 2014 at 11:01

GoogleCodeExporter commented 9 years ago
Just wanted to update that the bug is still present unchanged in version 
1.8.12. And it really is confusing if one of the main benefits of a shell 
extension – giving a visual overview – gives wrong results. I might as well 
not use it in these cases. I'd consider this a major issue.

Original comment by yves.goe...@gmail.com on 3 Feb 2015 at 3:28

GoogleCodeExporter commented 9 years ago
Have you also tested the latest preview release?

Original comment by sstrickr...@googlemail.com on 3 Feb 2015 at 3:48

GoogleCodeExporter commented 9 years ago
TortoiseGit 1.8.12.2 (20150131-f6a9732; C:\Program Files\TortoiseGit\bin\)
git version 1.9.5.msysgit.0 (C:\Program Files (x86)\Git\bin)
Shell icons: Shell extended

Went into a subdirectory of a clean working tree and changed a file. The file 
was marked modified. Went to the parent directory and the subdirecotry was 
still green. First issue, still present.

Switched to Shell icons: Default. Then it has updated all icons. Editing the 
changed file back to its original content worked fine. Other edits were also 
displayed correctly, but that's normal. The bug always appears after some time 
using it.

Reading the change log and seeing this first behaviour, I'd say the bug is 
still there.

Original comment by yves.goe...@gmail.com on 4 Feb 2015 at 10:40

GoogleCodeExporter commented 9 years ago
Same version. After merging master into another branch with lots of changed 
files (and two resolved conflicts), nothing was updated. Most directories had a 
red icon, but the working directory is clean.

As always, switching the "icon overlay status cache" from Default to Shell 
extended updated the icons again. Next time, a switch back will help.

So, yes, definitely, the bug is still here.

Original comment by yves.goe...@gmail.com on 10 Feb 2015 at 11:18

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Now, "Shell extended" has failed after two simple commits and marked all 
differences from before the first commit of today. Switching to "Default" 
updated the icons quickly. Now we've had all possible scenarios of this bug. 
I'd say the icons feature is pretty unusable like this.

Original comment by yves.goe...@gmail.com on 11 Feb 2015 at 10:35

GoogleCodeExporter commented 9 years ago
It's happened once on my machine as comment #9 and #10 mentioned.
No immediate update in few seconds makes me sad, 
but switching cache mode between Default and Shell extended makes me not so 
sad. 
(I hope I can fix it. And I was inspired by git index file. ^_^ )

Original comment by yuelinho...@gmail.com on 13 Feb 2015 at 3:23

GoogleCodeExporter commented 9 years ago
Can you please test our preview release 1.8.13.1?

I found a bug in 1.8.13.0 which caused vanishing icons resp. files being 
displayed as unversioned and yesterday I also fixed a caching issue (sometimes 
the latest status of tgitcache wasn't propagated to explorer).

Original comment by sstrickr...@googlemail.com on 29 Mar 2015 at 4:00

GoogleCodeExporter commented 9 years ago
@Yves: Is this better with our latest preview?

Original comment by sstrickr...@googlemail.com on 7 Apr 2015 at 1:51

GoogleCodeExporter commented 9 years ago
No, release 1.8.14 still has the same annoying bug.

Original comment by yves.goe...@gmail.com on 22 Jun 2015 at 9:36

GoogleCodeExporter commented 9 years ago
we just have a preview release 1.8.14.1.
Could you please also try it?

Original comment by yuelinho...@gmail.com on 22 Jun 2015 at 9:48