Open GoogleCodeExporter opened 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:
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:
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
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
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
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
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
Have you also tested the latest preview release?
Original comment by sstrickr...@googlemail.com
on 3 Feb 2015 at 3:48
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
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
[deleted comment]
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
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
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
@Yves: Is this better with our latest preview?
Original comment by sstrickr...@googlemail.com
on 7 Apr 2015 at 1:51
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
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
Original issue reported on code.google.com by
yves.goe...@gmail.com
on 2 Oct 2013 at 10:51