slow, buggy, does some crazy disk i/o that slows down my entire computer, ** in ignore doesnt work, vs get hung in this git2-msvstfs.dll!_git_graph_ahead_behind method for over 10 minutes sometimes at startup, visual studio stays running even after close now and it causes visual studio to lock up all the time. I get these weird cannot stat file errors where I need to go and physical delete a file in bin folder generated by the build. Also the Add icon looks almost exactly the same as the unmodified icon. Wouldnt recommend.
Yesterday after working for couple hours taskman showed 100s of gbs of read i/o. The issue resolved it self after I deleted a file in test results folder that was locked by sql server. After that I tried to open another solution, after waiting five minutes I just gave up and uninstalled.
I switched to the 3rd party "Git Source Control Provider" with tortoisegit. So it is great, no issues perf issues. Probably wont be checkin anything until monday so will know more by then. All I need is add files and commit in stable way, everything else I do from command line. So if it does that without perf issues then its a 5/5 for me.
Very, very unstable for me. I constantly have issues committing due to odd 'File In Use' errors, the plugin constantly doesn't add files to git that I've added to my projects and so missed commits happen frequently. Just not ready for prime time.
I've been trying hard to use this thing shortly and already going furious.
-no stash support -no rebase support -no interactive rebase support -files with unconfirmed merge conflict resolution are presented as Pending Removal
This tool albeit having Git in name actually promotes quite the opposite, central fashioned methodology and effectively discourages practises invented and intended for distributed systems like Git. I mean, really?
I like the conflict resolution view.
Apparently the only viable way of collaborating and keeping working copy refreshed by other contributors is to: 1. Commit (or revert) unfinished changes before pulling from upstream. Commit for the sake of commit. Reminder: no stash. 2. Pollute history with unorganized heaps of commits. Reminder: no stash, no rebase, no interactive rebase. 3. Delegate unsupported but mission critical operations to other tools. Why not stay with them and avoid VS Git placeholder in the first place then?
The way this tool is integrated in VS and what capabilities it exposes (or better hides) is a total bummer and discourtesy to any self respecting Git user. On the bright side: 9/10 masochists disagree.
It's ok, but nested .gitignore files are not properly considered (or overriding properly). The Git GUI shell extension for Windows works perfectly fine with my .gitignore files, but nested ones are not handled properly by this VS extension, and files that should be hidden using wildcards are still showing. For example, in one .gitignore file (in a parent folder) I have: /Source/*/*.js /Source/*/*.min.js /Source/*/*.js /Source/*/*.map **/DSJS/*.js **/DSJS/*.map **/DSJS/*.min.* **/DSJS/*.txt And in another .gitignore in a the sub-folder (/Source/DSJS/) I have: /*.js /*.map /*.min.* And all these files types still show.
This is really helpful for working with Git in Visual Studio.
I would like to be able to use an external diff / merge tool (Beyond Compare). I got really used to that when using TFS. Unlike command line git, this extension seems to ignore the diff.tool and merge.tool settings in .gitconfig.
I would like to request that you either use those settings or add an option in the Tools/Options/Source Control/Configure User Tools menu a la TFS?
Visual diff and history in VS is great, and some of the branch management is good.
The features that are missing, like tag and blame, I don't use as often, so reverting to command line or 3rd party tool isn't a big deal.
However, there's a deal-breaker, which is the behavior with ignored files: the ms-persist.xml file. Some tools (SlowCheetah among others) add ms-persist files within the .git folder, and then Visual Studio uses those as overrides to the .gitignore settings. So, a file that is ignored (explicitly by me in .gitignore) is included when/if some random ms-persist file exists. Of course, the git command line tool and other 3rd party tools don't use or honor the ms-persist settings, so committing from them is right.
It works OK with VS2013... but in VS2012... I get an error message (on the Team Explorer top-righ view corner "object reference not set to an instance of an object" with a red triangle... This is quite bad, because a lot of team members don't have VS2013 (which has no issues).
Prereq checks are broken. Stuck on wanting 2012 Update 2, but that is rolled up into Update 4. Which is already installed. So the install is totally blocked. Updates and patches are going downhill.. more and more broken/blocked/breaking-things. Need to prove these things to yourselves on a broader level.
This is not installable on the resulting version of visual studio from a SSDT/SSDT-BI install, so it appears that git cannot currently be used for SQL Server development when a full blown version of visual studio is not also installed. Seems rather strange that express products are supported when SQL Server developers are not.
Connect bug is here:
We use git with TFS but we didn't see the our avatar pictures on the different windows except the picture of one college. We have check and we have a picture in the TFS online portal. We use TFS integrated with the active repository.
First: I like Microsoft Git Provider
Maximilian added this issue:
And I agree with him. If you say that a certain file should not be included in source-control by adding it to .gitignore it should be respected. If a developer adds that file or if you have build targets that does it (automatically) it will still show up in the "Included Changes" list, even if it is excluded through .gitignore. I found it very confusing. Git does not behave that way and "Git Sourece Control Provider" does not behave that way but "Microsoft Git Provider" does. The consequence will be that files will be added to source-control by mistake because you forget to exclude them.
If this is not the right place to report this kind of issue, please tell me where to do it.
I am in agreement with Hans/Maximillian, the gitignore issue not respecting what we have set to be ignored causes a lot of conflicts in our dev team. So much so that they are wanting to throw out Git. Please correct this issue as it is not the way Git was intended to work. Thanks.
Any resolution on this issue? I see the official bug listed as closed, fixed in Update 2. I am currently using VS 2013 Update 3 and still experiencing the bug. Has Update 2 resolved the bug for you? Have you tried Update 3?
I'm hitting the same issue. 10 year old project imported into VS2012. Added to source control via Solution Explorer context menu. .ignore file modified with latest from github for VS. When committing, ALL files get committed! As if .gitignore didn't exist. This is a bug that needs fixing ASAP. When can we expect it?
Here is a post with an answer that worked for me. In case the link is broken, the answer from Eric Nelson is :
Close Visual Studio.
Navigate to your .git folder
Restart Visual Studio
I am getting two errors
1) On Setting click
System.ArgumentException: Value does not fall within the expected range.
2) On Connect click
System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.
This works fine in my VS2013 install. I need to add it to my VS2012 install. When I run the setup program, I receive an error that says "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." I have tried repairing VS2012 as well as running the Windows 8.1 Update troubleshooter. Thanks for any help.
Im trying to clone a repository from a visualstudio hosted repository but I get this error all the time,
An error occurred. Detailed message: An error was raised by libgit2. Category = Zlib (Error).
Failed to inflate packfile
I have tried changing the destiny location but without results... Can it be wrong URL repo? can someone help me here? Thanks a lot in advance!
An error was raised by libgit2. Category = 21 (MergeConflict).
4 uncommitted changes would be overwritten by merge.
The error always occur on nearly every project. Everytime I need to remove the whole repository and clone again to solve the problem.
I even can't revert the changes made in local commit and can't push the changes to the server because only 1 incoming commit stuck.
I have tried to click fetch, pull, and sync, no one make it works.
Could anyone help to solve the problem?
Really appreciate for anyone could help!
Calvin, thanks for reporting this. I'm guessing you see this error when you actually try to perform a merge? If you've seen this happen to multiple clones of your repo then I am guessing there is something special about your repo that libgit2 doesn't like. Can you send me an email at taylaf at microsoft dot com so that we can work on getting a repro in house?
I also have this problem. It happens EVERY TIME both I and someone else on the team have committed to the master branch. No, I do not do anything, especially not merge (how do I do merge? there's no option for this). I simply click the SYNC button (or Fetch or Pull - these do the same), and I get the error. So far, the only way to get rid of the error is to download a fresh copy of the repository, thereby losing ALL my changes. This is a SHOWSTOPPER.
Also the same here! If you have local unsynced commits or changes then you can't sync. (An error was raised by libgit2. Category = 21 (MergeConflict).
4 uncommitted changes would be overwritten by merge.) If you try to push your changes before pulling there is also a error message. (If it occurs next time i will add the push error message)
Tis is really an showstopper and we can't start with productive work on our new TFS before this is solved! A real Merge dialog would be nice but a good automatic merge, without destroying the local changes, would be enough for now!
I've just hit this issue as well. We have a brand new tfs-git repo and I've Cloned and done a bunch of commits and syncs. Someone else just cloned and added new files in a completely different folder, so there's no content level differences which can be diff/merged and no button for it. Surely I don't need to create a new branch every time someone else pushes a change? I wouldn't think that would make a difference anyway.
Anyway, this seems to be a massive problem, so any response would be great. has been over a month since the last post here.
The GUI seems to be buggy.
If I click Pull on Incoming Commits, I get the error referenced above "libgit2. Category = 21 (MergeConflict)...".
When I open the Git Command Window, then type "Git Pull" it resolves the simple merge and completes. Why are these different?
Same thing is happening here, almost every time I try to pull (from team foundation service) in VS it fails with An error was raised by libgit2. Category = 21 (MergeConflict)..
Pulling from command line works fine.
Same thing here, we can no longer push, pull, or sync...I assume Microsoft would be working on this serious issue or at least get some information out to us so that we can work on a resolution ourselves. This issue literally makes it impossible to use GIT in VS2013.
The same thing happened to us. We believe it was from a series of .gitignore updates by a couple of developers. When the conflict came up, there wasn't a way to merge it so they were stuck. Visual studio doesn't seem to see those files from that point of view. I'm sure there's a way to do it from the command line but since there were minimal other updates, we just re-cloned the repo
If you encounter this problem, start the Git UI, cancel the merge and do the merge again in the Git UI. 95% of the merge problems can be solved that way.
Another solution is using the command line. This is especially true if you have "uncommitted changes" while visual studio shows you none.
If the git tools are in your path, use powershell or cmd or even the package manager console if you don't want to leave visual studio.
> git status // gives you an overview of the commit status
> git add -A // adds uncommitted files to the list of files to be committed
> git commit -m "some useful comment" // commits the files.
Try the merge again and if it still fails, do the merge from command line.
> git merge <branchname> // while being on your own branch
if you have merge conflicts and visual studio stubbornly refuses to let you use the merge editor
> git mergetool //launches the mergetool - if correctly setup, the VS one.
Has there been any development towards getting submodule support working? There has been a petition for this since January 2013 here: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3606383-add-submodule-support-in-visual-studio-git-extensi
Could someone from the team have a look at the problem posted in connect:
It seems like someone had a look at it before and fixed it, but we are still experiencing issues...
Whenever I launch visual studio 2012 (no solution is open), there is a delay, after which i see in output "Opening repository: ....". Why is it doing anything at all? I haven't opened the solution within that repository. How can I disable this?
I guess the problem is I really only wanted the 'compare with unmodified' context option, I already use SourceTree for all other git operations. This extension assumes that every time a user starts visual studio they may be doing arbitrary git operations without even a solution open. I guess that's possible, but if I do not have the team explorer tool window open, and I don't have the git extensions tool-bar enabled, then why does it need to do this work on startup?