At times, the TortoiseGit Windows shell overlay is wrong, indicating modifications when there are none.
The cleanup command looks too heavy handed, none of the Clean Type options are appropriate and will remove needed files.
Is there any other way to force TortoiseGit to update the shell overlay?
There might be several reasons why the overlay icons are wrong.
One common reason is if filenames differ in casing (even if NTFS disregards casing, Git still honours it, even if core.ignoreCase is set; cf. https://tortoisegit.org/issue/2980).
If this is not the case, try to restart TGitCache (cf. https://stackoverflow.com/a/32427524/3906760) or try to use another overlay handler (Shell or Shell Extended; cf. https://tortoisegit.org/docs/tortoisegit/tgit-dug-settings.html#tgit-dug-settings-overlay).
I have found that sometimes Windows Explorer is slow to update the status of a file e.g. still showing uncommitted changes even though all changes have been committed. Refreshing the display by hitting F5 or choosing Refresh from the right-click menu usually fixes it.
Related
I'm having problems trying to set my Custom Shell in Github for windows to Console2.
It seems like no matter what I try it wants to ignore my setting and just launch in powershell.
Under Github for Windows I have the path for my custom shell set to where I have Console2 installed and the checkmark is next to Custom. (double and triple checked this for sanity)
I've tried restarting my computer multiple times, and even changing the setting to the other options (ie cmd and Git Bash).
In all 3 cases launching gitshell still launches Powershell instead.
I tried to search around here and google but haven't found anyone having a similar problem. Is there anywhere (ie registry or db file) where I could check to see how these values are set, and try to override it? Or if anyone else has experiences this problem and has a solution I would greatly appreciate it!
I'm having the same issue as well. As a workaround, choosing "Open in Git Shell" in the gear menu of the GUI client is opening Git Bash (my shell of choice) in the repo I'm in, but this only allows one terminal window and isn't a true solution.
I'm guessing a bug was introduced in one of the recent Windows client updates. I'm going to let them know about it at https://github.com/contact and I suggest others do the same if they also have this issue.
I am working on Windows 7 with Source Tree. Because I don't like the default cmd.exe I want to change it to Console2 such that Source Tree will open Command2 instead of Cmd as terminal.
It appears you can't do it, at least in any obvious way. There are a couple of solutions/workarounds that you can use here:
Pick a different favorite terminal. ConEmu is a wrapper for CMD.exe that will act as your default terminal if you tell it to [I thought Console2 could do this as well]. Also - forgive the editorial - ConEmu is way, way, better than Console2.
You can add a custom action in the menu. From the global options go to Custom Actions tab and add an action to Open in Terminal using the console you want. This isn't quite as cool as just hitting the terminal icon, but you can easily accomplish the same outcome.
Unfortunately, these are the best there are for now.
Note: Based upon the link that #sendmoreinfo posted, waiting for Atlassian to add this by default may be better way to go for your purposes. Only problem with that may be is that according to some the newest updates to Source tree are terrible, so I haven't updated as of yet.
Note 2: Though this won't do what you want, there is an Option in the settings under the Git Tab that allows you to Set Git Bash as default prompt. That may or may not get you closer to where you want to be.
You may add Windows Terminal as Custom Action. You may run custom action in context of selected file. Define a new custom action as shown below.
I've been playing around with a Windows 7 virtual machine and found that by changing the shell registry value in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\shell I can use an arbitrary program (for example, paint) as the shell instead of explorer.
Now, given that I have no access to the tools afforded by explorer, how would I go about reverting this? This seems like a rather useful trick for demo machines and such, so I would hope that there's a way to revert them when done.
It turns out that keyboard commands (C-S-ESC, C-M-DEL) still work. Surprisingly, windows-r doesn't work. To revert it, open the task manager using C-S-ESC, then click new task, then you can either run explorer to start the gui shell, or regedit to change the default shell.
On my computer at work, any time I open a file located on a network share, GVim becomes completely unusable. Scrolling through the document can take 15 seconds to go one "page". Even using the movement keys to go from one word to another can take 2 to 3 seconds. This seems to be a new behavior, but for the life of me I can't remember changing anything that would cause it. I'm under the impression that Vim doesn't actually access a file except on open and on save. Is that right?
There are a few factors which may affect this.
First, make sure you have Vim setup to prefer storing the swapfile locally. If your $HOME is on a local drive, I tend to put this in my vimrc (which will either be at $HOME\_vimrc or $VIM\_vimrc). Make sure you create that directory, otherwise Vim will continue to use one of the other directories in the list.
set directory^=$HOME/tmp
This prepends the $HOME/tmp directory to the start of the list that Vim checks for where to place swapfiles.
Second, do the same for the backup file that Vim creates. Same situation as above but the option you'll be changing is backupdir instead of directory.
Third, make sure you disable the matchparen plugin. This plugin is new to Vim 7, so you may be used to using an older version of Vim. This causes frequent scanning of the file for matching parens, braces, etc. which can drastically slow Vim down when the file is on a network share. Again, this should go in your vimrc.
let g:loaded_matchparen = 1
If you only want to disable the plugin temporarily, you can use the command :NoMatchParen and then :DoMatchParen to re-enable it later in that Vim session.
Finally, if none of those help you can always copy the file locally and edit it.
Swap file has nothing to do with it. I have my swap file local and still have the problem. I use Process Monitor from SysInternals.com and it revealed bad behavior when attempting to open "\server\TestTool\foo\ReadMe.TXT"
It first attempts a CreateFile (aka, Directory open) on "\serve\". Notice the last character is missing. This will cause 4 seconds to time out with "OBJECT PATH INVALID".
Then it tries CreateFile on "\server\TestToo\". Server name is correct by the last letter of "TestTool" is clipped. Again, a 3 second time out with "BAD NETWORK NAME".
Finally it gets it right and calls CreateFile on "\server\TestTool\" which works right away.
Then CreateFile on "\server\TestTool\foo" which works right away.
Then CreateFile on "\server\TestTool\foo\ReadMe.TXT" which works right away.
WHY is it trying bad names for the server and the root directory??? What madness is this?
I fixed this issue after setting HOME path by force in advanced system settings.
(Your current HOME path would be a network directory.)
Control Panel > All Control Panel Items > System > Advanced system settings > Environment variables
Press "New..."
Variable name: HOME
Variable value: c:\Home\ **<-- Type your home directory**
A follow up on jamessan's answer: to disable the plugin automatically when you edit files on a share, put this line in you _vimrc
autocmd BufReadPre //* :NoMatchParen
You could consider installing LargeFile plugin. It disables a couple of features impacting the performance.
Having a similar issue as David Anderson, but no solution yet.
When loading \\ServerName\A$\B\C\File.txt Vim will do:
Open \ServerName\A$\B\C\File.txt
Then it does many loops like:
CreateFile \ServerName\A$ <-- Each taking roughly 1 sec
QueryDirectory \ServerName\A$\B
QueryDirectory \ServerName\A$
QueryDirectory \ServerName\A$\B\C
QueryDirectory \ServerName\A$\B
To compare with Notepad++ which loads files almost instantaneously there are more lines and Notepad++ never queries \\ServerName\A$.
Also the duration (Duration column) written in Process Monitor is low, but the time taken by Vim seem quiet high (Time of Day column) for the CreateFile \\ServerName\A$.
I've no plugins installed as far as I know and followed other tips to speed up network shares loading.
Note: The dollar is in the path. More weird is that Vim will load very fast on more recent Windows Server (2008 instead of 2003) with the same folder structure.
I had the same problem (slow gvim editing over network drive) and have fixed it. It was for me -- no kidding -- the titlestring.
Background: I use a vertically arranged taskbar with Windows 10. This has the advantage that my open windows behave like a growing stack from top to bottom. For example, see here some currently open windows with how-to-run.txt as a network file:
With that it makes sense, that the filename is going first in the window title of gvim and the path goes after that. So I used exactly the titlestring in my vimrc, which is still officially recommended in the help file vim81/doc/options.txt, line 8202:
set titlestring=%t%(\ %M%)%(\ (%{expand(\"%:~:.:h\")})%)%(\ %a%)
For local files that's ok, but for network files this is way too slow.
Now my fix:
set titlestring=
Same effect (filename first), but now gvim runs very fast for remote files as well!
BTW, I also tried all the above mentioned recommendations (directory, backupdir, matchparen, disabled all the plugins, tried the LargeFile plugin although I observed the slow gvim also for small files, etc.). I also changed my statusline to something really simple.
It all had no effect for me. But the funny titlestring...
One of my programs seems to be changing the Display Properties > Appearance > Effects > Show window contents while dragging setting to off every few hours.
I'm not sure exactly which program, or when it happens. I have a number of programs that seem like likely culprits - wallpaper rotators, software for multiple monitors, multiple virual desktops and switching, and a few others.
I am just thinking to create a little batch script to run periodically and set the setting back to on.
Does anyone know how to do this in windows? I'm using xp pro sp3.
Thanks!
The best option is to do this programmatically using the supported API. i haven't tested this, but it should do the trick:
SystemParametersInfo(SPI_SETDRAGFULLWINDOWS,
TRUE,
NULL,
SPIF_UPDATEINIFILE | SPIF_SENDCHANGE)
You can use SPI_GETDRAGFULLWINDOWS to see if the the bit has been flipped to avoid unnecessarily triggering a WM_SETTINGCHANGE.
You can use RegMon to find the program that keeps changing your settings. Maybe that's a better start than hacking around it.
There is a simple and effective solution to this problem. In Notepad type the following lines :
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\Desktop] "DragFullWindows"="1"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects\DragFullWindows] "CheckedValue"=dword:00000001 "UncheckedValue"=dword:00000001
Save the file as "Show Window Contents.reg" Double clicking this file and restarting will cure the problem permanently. Post a message if you find this useful.
Aravind Banerjee
It seems the registry setting which controls that preference is HKCU\Control Panel\Desktop\DragFullWindows. You can read more about it here. However, trying it on my own computer does not register the change right away, so a batch script won't do it. You'll probably have to write a program to manipulate it using SystemParametersInfo(). You can pass it the SPI_SETDRAGFULLWINDOWS parameter. Here's a page explaining it more. Here's a page showing how to call it, albeit not for the same parameter.
I suspect it's kept in the registry - maybe [HKEY_CURRENT_USER\Control Panel\Desktop] - "DragFullWindows"?
It would be easy to flip the registry setting back to "1" every hour or so with a batch file.