- Automatically refreshing the CodeLens for git team indicators to reflect the current source control state
- Improving the user experience in the case of big files with a lot of changes
- Adding the "when last changed" information to the authors indicator
- Adding work items indicators for TfGit
CodeLens for Git indicators now react to Git source control operations
In the CTP1, the authors and change indicators that we introduced did not refresh automatically when source control operations occurred. As a user, you had to manually refresh the indicators using the contextual command (or close and reopen the file)
In this RC, all the CodeLens for Git team indicators now refresh automatically when you:
- Commit a change (the number of changes may be incremented, and the author may be changed)
- Pull, or Sync your repository (you may get new changes)
- Change the branch (the code and its history may be different)
The refresh occurs when performing these actions from Visual Studio or from any other tool, including the command line.
Improved experience for CodeLens for Git indicators used for big files with a lot of changes
In Visual Studio 2013 Update 3 CTP1, the authors and change indicators could take some time to appear, especially in the case of source files containing a lot of code elements or having a big change history. When that occurred, we received feedback that the users could not tell if something was broken, or that there were no change, or if it was just taking a lot of time. This was not an issue with the TfVc CodeLens team indicators, as they retrieve pre-computed data from the Tfs server. But since the processing occurs locally on the client for Git indicators, we had to let the user know that the computation was being done.
In this RC, the Git collaboration indicators shows dimmed placeholders while data is being computed, similar to the reference indicator:
Then, as things get computed, the numeric information appears and the color of the indicators get darker:
New "When last changed" indication
In addition to the latest author, and the number of additional people who have changed the code element, we now display how long ago the last change happened (31 days ago in this case)
New work item indicator
When TFS work items are associated with commits
As was explained in the previous blog entry, the CodeLens for Git indicators work with any Git repository. In particular, they also work for Git repositories hosted in TfGit, either on premise, or in Visual Studio Online. In that case, you might be using Tfs to manage your work items.
When you are connected to a Team Project Collection (either from a TFS server or VS Online), and when we recognize that commits were associated with work items, we display another indicator, the Work item indicator telling you the number of work items associated with all the commits involving this code element.
When you click on the indicator, we go to the Tfs Server
And we get the work item details
As in the case of the CodeLens for TfVc indicators, you can navigate to the work items (this will open a tab in Visual Studio), or to the commit, which will appear in Team Explorer.
Of course, as in the case of TfVc CodeLens team indicators, we also changed the changes indicators popup to add the work items associated with commits:
As an aside, you might wonder in the image below some if the instances of the author have a green Lync presence indicator (meaning the author is currently available on Lync), and others show the same author as absent. This is because I did the commits with 2 different credentials (but the same display name). In one case I used my Microsoft Id, and when the organizational ids became available in VS Online, I started using my corporate ID, for which I show-up as available right now.
Deeper dive into what it means for commits to be associated with work items
Here I’ve double-clicked on the commit, and I can see the commit details in Team explorer.
The reason why CodeLens for Git knows that there are two work items associated with this commit is that the last line of the comment is of the form:
Related Work Items: #1, #3
This way, without any call to the TFS server, the Git CodeLens indicators know how many work items the commits are related to. But they don’t know:
- If these work items are in TFS or in another source control system
- Which Team project collection this is related to (if at all in TFS)
- Any details about these work items (what kind of work items they are, their title, etc …).
CodeLens only attempts to fetch this information when the pop-up is displayed. Therefore it might happen that:
- You are not connected to a Team Project Collection
- You are connected to another Team Project Collection.
- You are connected to the right Team Project Collection but don’t have the necessary permissions to see all the work items
- Someone wrote in the commit description the line expected by TfGit to describe the related work items, but some of the work item ids don’t correspond to work items in the current TFS.
What happens if you are not connected to TFS, or are connected to the wrong Team Project Collection?
In the case you are not connected to TFS, or are connected to the wrong Team Project Collection, you’ll get a message when trying to see the details popup for the work items indicators. If that happens to you, you will need connect to the Team Project Collection. Of course this will probably close your solution, which you will have to re-open, and then things will work.
Note to reviewers: I’m installing a latest RC drop to make a screen copy with the right color for the message
What happens if you cannot access some of the work items?
If you are not allowed to access some or all of the work items (or they don’t exist), the popup will display information for the work items that could be retrieved and a message informing you that not all of the expected work items could be retrieved.
As always, we are interested in hearing your feedback on this feature.
Please try it out, and let us know.