For whatever reason, this plugin was causing VS2012SP3 to crash in a variety of subtle and difficult to debug ways. Removing it caused VS2012 to become stable again. Unfortunate, as the plugin should have been very useful.
Git integration has become a lot easier with the new version. It still lacks some essential features, but it looks promising. Stuff like "Source control explorer" and revert changes would be high on my list.
I have just started using and it looks promissing. Any step toward GIT integration on Visual Studio should always be welcome. Despite the lack of features, this version does the kick-off on VSWS (Visual Studio Wonder Shell :D ) integration. This does not seem to replace regular GIT tools (at least yet). However, it a pleasure to you ask a complement. Gave it 4 stars because I consider it really valuable but it needs to be enhanced. Thanks
My VSTools For Git version is 1.0.0.
I really like this plugin
but one problem negates all advantages :
I'm using Resharper 7.x and declared-as-fixed problem with file blocking is still exists.
I've found the discussion on Resharper support site - http://resharper-support.jetbrains.com/entries/24790716--Refactoring-failed-Files-still-read-only-error-message-when-applying-Quick-Fix .
This also confirms my words.
When this problem will be fixed?
In my solution I have a submodule (Bootstrap) that introduces long paths (>256 characters) to my project. Because of this, I cannot commit through Team Explorer:
"An error occurred. Detailed message: An error was raised by libgit2. Category = Os (Error).
Failed to open directory '<path to my web project root>/Assets/bootstrapcustomization/node_modules/grunt-contrib-qunit/node_modules/grunt-lib-phantomjs/node_modules/phantomjs/node_modules/npmconf/node_modules/ini/test/fixtures/': The system cannot find the path specified."
Ignoring the long paths won't help either. Thus, I am forced to make all my commits through CLI tools.
I have a Git-server at remote location (with Gitolite) hosting my Project repositories.
How do I connect this remote Git server (Username=MyName, ServerName=MyServer) to Visual Studio 2012-Express.
Generally I use cygwin fot this purpose, and I use ssh for connection with the server.
Can anyone guide me through.
When trying to sync a repository when a push and pull is required Visual Studio is telling me that merge conflicts are preventing me from doing the sync.
Before when using VS 2013 RC a merge dialog would appear allowing me to complete the merges within visual studio. However after installing VS 2013 Ultimate that merge resolution has disappeared for both myself and a colleague.
We are now left with an error message from libgit with the Category = Checkout (MergeConflict)text.
Any help would be appreciated.
We have the same problem here, using VS2013 premium. Almost every pull ends up with "An error occurred. Detailed message: An error was raised by libgit2 (mergeconflict)" and nothing else.
When we then pull using commandline or tortoiseGit, usually there are no conflicts that has to be manually resolved.
Directories containing git submodules always show up as dirty in the changes panel.
I have tried storing submodules directly in a directory, in a symlinked directory, and in a ntfs junction directory; I have added the directory to .ignore; I have tried git update-index --assume-unchanged.
In all cases, command line status reports no changes, while the changes panel reports it as a change.
Is there a way to make submodules to play nice with the changes pane, or is this a bug/missing feature?
Clicking on Team Explorer -> Changes I'm getting an error:
Page 'b38f4abc-2b2c-4e4d-a047-eaaca7514610' not found.
Page 'b38f4abc-2b2c-4e4d-a047-eaaca7514610' not found.
Page 'd0e4ea4e-24f0-46d6-9d07-0bc09cdeae7d' not found.
Microsoft Visual Studio Ultimate 2013, Version 12.0.21005.1 REL
Getting the same error on running the latest downloaded setup in Repair mode, and Uninstall then Install:
There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.
There is a thousand of 101% useless menu bar items. This extension brings a hundred more.
But why there is no very useful one - to open pending changes? Meaning Team Explorer -> Changes when Git is the active provider.
I set up my Visual Studio 2012 with cloud TFS using this extension. But I can not integrate it with an external diff tool.
In TFS source control I am able to configure the external diff tool using "Configure User Tools...". There are no such options when I use GIT as source control.
I noticed, that Visual Studio creates a local diff scheme for the repository - vsdiffmerge. I tried to change the path to the diff tool there, but it didn't help. Of course, my custom diff tool is set as default for GIT.
How can I set my Visual Studio 2012 to open comparison in the external diff tool?
Yes this is an important feature of a Source Control Provide for Visual Studio. This is the first one I have used that didn't provide a way to use an external diff/merge tool. Even TFS provide built into VS provides for this, and so does several SVN ones I have used.
I have been using Beyond Compare since its early 1.x days and so far nothing has come close to being better than it, and even though the included Diff tool included with VS2012 and 2013 is much better than anything they have provided before it still doesn't compare with Beyond Compare. In order to use a source control provider this is critical that I can use my own prefered diff/merge (3way merge as well) tool.
Please include this in a upcoming release. While I prefer a Microsoft created Source Control provider I will be going back to the Yiyi Sun provided extension. I will switch back once you have external diff/merge tool support, as your integration otherwise is much better than his.
When trying to clone a repo to a working directory on a network share (that was mapped to a drive letter, so we're not using UNC paths), we get "Failed to inflate pacfile" in the team explorer window. When using a local directory, this works without a problem. Any ideas why? Workaround?
After upgrading to version 220.127.116.11, we are having this same trouble. Local repo's stored on local drives (C: for example) work fine. But, VSTfG returns "failed to inflate packfile" error anytime we try to clone to a network drive (whether mapped or UNC path specified).
Before the upgrade to 18.104.22.168 we were using 0.9.0.0 and finally had that working fine with local repo's, using UNC paths, after doing initial clone via GitBash command line.
Now, even our existing projects that had already been cloned while on 0.9.0.0 and were working fine to push/pull to remote repo's, can no longer pull from those same remote repo's (push op's still work, however).
Interesting. I tried to clone from remote repo, using UNC path to specify local repo path, but the clone consitently failed with the "failed to inflate packfile" error message.
Perhaps it's worth illustrating our setup and the variations I've tried. Consider this scenario...
Remote repo on network share \\serverA\shareA\project.git, mapped as R: drive.
Local repo destined for network share \\serverB\home\username\project as L: drive.
Using the above scenario, all of the following failed in trying to complete a clone:
\\serverA\shareA\project.git => \\serverB\home\username\project
R:\project.git => \\serverB\home\username\project
R:\project.git => L:\username\project
\\serverA\shareA\project.git => L:\username\project
However, clone to local path worked fine, like \\serverA\shareA\project.git => C:\temp\project.
I retested and I was wrong...fetch/pull/sync don't work from within Visual Studio with VSTfG 0.9.0.0 or 22.214.171.124 when local repo is on a network share (UNC or mapped), neither does clone.
Whereas, all of the above work fine (eitehr version) via command line GitBash.
Why would VSTfG not be able to support network drives? Seems silly.