Visual Studio Git - Slow on large repositories - by James Rhodes (PageUp)

Status : 

  Duplicate<br /><br />
		This item appears to be a duplicate of another existing Connect or internal item.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 790343 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 6/17/2013 6:28:05 PM
Access Restriction Public


Currently we are trying to use the Visual Studio Git extension on a very large repository (2 years worth of history and around 28000 files).

Unfortunately it seems that the extension updates it's status information by rescanning the entire repository every time a file watcher notices a change.  This is very inefficient and it causes the IDE to lock up whenever a file is opened in the repository (as it does a full rescan before the IDE responds again).

A better approach would be to use the file watchers to perform delta updates on the known status of the repository (so if a file watcher notices a change on one file, it only rescans the status on that one file).  When the user actively interacts with the commit window, and no rescan has been performed within a period of time, then and only then should the IDE do a full rescan of the repository to update the status.  In particular, when staging and unstaging files, it should only rescan the relevant files and not do a full rescan.

It should be noted that other Git tools such as Git Extensions do not suffer from the same performance issues, so this is something that can be fixed.
Sign in to post a comment.
Posted by Taylor [MSFT] on 7/2/2013 at 5:21 AM
Hi James,

That is great to hear that this is fixed in the release. You are correct that this fix has not made it into the VS 2013 Preview. Please be assured that it will make the next public release of VS 2013.

Posted by James Rhodes (PageUp) on 7/1/2013 at 9:07 PM
This is now fixed as of, however the fix is not yet available for Visual Studio 2013 Preview which still experiences the issue.
Posted by Matthew [MSFT] on 6/19/2013 at 8:51 AM
Hi James,

Just an FYI, we're already tracking this issue with another bug that we filed internally, so we're going to close this bug at this time. If you are able to share your repo with Taylor (per his previous request) we would still love to use it to verify our fixes for the perf isues.

Program Manager | TFS Version Control
Posted by Taylor [MSFT] on 6/19/2013 at 5:24 AM
Hi James,

Thanks for the feedback! This is complaint we've heard a few times now and is one we are actively in the process of fixing. We are planning to address this problem in our next release which should be out within the next few weeks. We've reproduced this issue with a few different repositories but we are interested in doing more validation. If you would be interested in sharing your repository with us so that we can guarantee that we have fixed this issue for you, please reach out to me at and we can set up a way to transfer the repository.

TFS Version Control
Posted by Microsoft on 6/18/2013 at 11:33 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Macy [MSFT] on 6/17/2013 at 6:51 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(