6

One of my colleagues uses a Windows 7 machine with TortoiseGit and it is tortuously slow even just running a git status. He is using the TortoisePlink method of connection and key serving.

Each commit is taking about 5 minutes before the changed files list is populated let alone the actual commit itself. Pushing and pull take even more time and woe betide him when there is a merge conflict!

I am unsure what is causing it to be so slow as all operations appear to be compromised not just those that access the network (push/pull/etc).

The one caveat to all of this is that he is operating on files that are shared over Samba from an Ubuntu 10.10 box.

I have not had any luck getting it to run any faster on his machine by removing and re-installing TortoiseGit and MSysGit. Any other ideas to make it faster?

He is using TortoisePlink to be able to make use of Pageant and multiple keys.

0

4 Answers 4

2

Are you saying that the repository he has cloned is on a Samba share, or that he's actually directly using a working directory on a Samba share? If it's the latter, I'd strongly recommend cloning the repository locally (that's how git is supposed to be used). If not, I don't know why local operations such as status or commit are so slow. You might want to try out GitExtensions with MSysGit; I'm using it on Windows 7 (on a local hard drive) and am very happy with it.

5
  • 1
    He has cloned onto a Samba share on the server and not on his local machine. The reason for this is we have a central development server for our web applications with each developer having their own sub domain. Which I have documented blog.simonholywell.com/post/1516566788/team-development-server for anyone interested.
    – Treffynnon
    Mar 15, 2011 at 10:17
  • A quick experiment cloning locally and cloning onto Samba shows markedly different results like you suggest. I am using Ubuntu and I work over the same Samba shares as well in the same way. My operations using git-cli over Samba is much faster and almost identical to the same operation performed on the server itself over SSH.
    – Treffynnon
    Mar 15, 2011 at 10:20
  • I don't have time to read the article right now (and I know next to nothing about Apache), but are the developers RDP'ing or SSH'ing into the server and working there (if so, they should clone onto a local drive on the server), or are they developing locally and deploying onto the server (if so, they should clone first onto the dev server and then from the dev server onto a local drive on their own machines, and push changes to their dev server repo)? Mar 15, 2011 at 10:57
  • I get what you mean. This particular developer does not have linux command line skills and works with HTML/CSS. So he works directly on the development server editing files via the samba share so he can see his changes in the web browser immediately. The git workflow you mention sounds good, but is a but cumbersome in practice given the type of work we do. It seems like I might have to look at the way his computer is working on the network.
    – Treffynnon
    Mar 15, 2011 at 14:44
  • Thanks for your help though and we are going to give GitExtensions a go at the end of the working day.
    – Treffynnon
    Mar 15, 2011 at 14:45
4

I think it's due to msysgit being slow when UAC is enabled on windows 7:

http://code.google.com/p/msysgit/issues/detail?id=320

1

In my case it was the icon overlays which were slowing down windows explorer. Uninstalled TortoiseGit and everything is lightning-fast now.

... and yes, I only had icon overlays active on my git repository folders. Not all the folders on my C: drive.

0

I was experiencing the same issue on Windows 7. TortoiseGit (especially log and rebase) immensely slow (5 or 10 min "not responding"), and win explorer right-click context menu as well (30 sec to show up).

Killing the "TGitCache.exe" process solved it. I found that workaround at: https://gitlab.com/tortoisegit/tortoisegit/issues/1797

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .