The major feature that is still missing from the Microsoft Git Provider is to integrate it with the Source Control Explorer window to provide a full featured Git repository UI that will rival third party tools in it's feature set.

A great example of the ideal functionality is the Git Extensions main user interface. It allows changing repositories and branches, stashing changes, committing code and push/pull operations. It also provides a great visual diagram showing the commit history for the selected repository and where each branch (local and origin) is in relation to the head. It also allows you to view the entire file tree for the selected commit along with the changes made in the commit (the Diff tab).

Source Control Explorer already has very similar functionality when working with the TFS source control plug-in. Almost all of those features in Git Extensions can be tied to a similar feature found in Source Control Explorer for TFS. Providing similar functionality to Git Extensions in the Source Control Explorer window when using the Microsoft Git Provider would go a long way to providing a robust IDE for use with Git that is a core feature of Visual Studio.

Patch adding allows to stage only parts of a file (hunks), not an entire file.
The command line equivalent is the command "git add --patch"

For example if you edit a file on line 20 and make another change on line 40 and now you want to split this changes into two separate commits because they are unrelated to each other you can do this by patch adding the file. It would be nice to have this functionality available inside of Visual Studio.

The same funcionality could be used to automatically include the changed parts of the csproj file when a file is added or deleted, so you never forget to add the csproj file to the corresponding commit.

If you are interacting with a file in a shelveset, you get 3 options to compare the file in the shelveset to:

1. Compare with Unmodified Version: shelved file vs. version last gotten in the workspace that made the shelf

2. Compare with Workspace Version: shelved file vs. version last gotten in the local workspace (but without any local changes)

3. Compare with Latest Version: shelved file vs. latest version in TFS

*** I frequently want this fourth option, which is notably absent ***

4. Compare with local Version: shelved file vs. version last gotten in the local workspace (including local changes)

Source Control Explorer list only fice columns (Name, Pending Change, User, Latet and Last Check-in).
Please add more columns, like Last Modified Date, History Present, etc. that will allow us to see the last modifeid date of the file and not just the date when the file was checked in to source control.
The excellent example is, when you move the files/folders around within Source Control, you are forced to check in the changes, which is every file in the project. Resuling into the same check in date for all files and folders within the project. Now I have to review the history for entire project to find out which file was modified last.

Allow "Compare working copy to historical version" version in TFS GIT 2015

http://stackoverflow.com/q/34123687/30225

When I pull up the history of the file I can compare that version with another version listed in the history by selecting both and doing a "Compare", or I can compare a historical version and its changes wrt to its previous version by selecting "Compare to Previous".
However, there isn’t a command that will let me compare a historical version in the history list to the currently edited version on disk.
This was one of the best features of TFSVC and I would be good to bring it back for the GIT support in VS 2015

Our development team (and every other team I've been on) hates the Git plugin for visual studio. We find it cumbersome compared to third-party tools or the command line interface. And it is a performance nightmare, especially with large repositories. This wouldn't be an issue if we could just disable the git plugin by setting it to none in the source control options menu. However, Visual Studio will ALWAYS reenable it if it detects a git repository in the directory of the solution.

We've resorted to regedit-ing to disable it.

If someone wants to turn off functionality, they should be able to turn it off. If you do a bad job writing a bit of software, don't try to force people to use it. Let them use their own tools where they don't like yours, and your tools where they do.