 Good morning Internet and welcome to another installment of the Visual Studio Remote Office House. My name is Matt Christensen, and thank you so much for joining me here today where we're going to learn about Git and working with Git Source Control in Visual Studio, and nowadays with all of us being at home, team collaboration is super important and it's changed its character. So having a great Git experience and source control experience is paramount. So I'm super excited that we today have a couple of program managers from the Git Source Control team within the Visual Studio organization to talk to us about what they've been working on. They have some really cool stuff. So let's just see what they have to say and let's move that into Tayser. Good morning, Tayser. Can you give a brief presentation of yourself? That would be fantastic. Thank you. Hello. Good morning. Thanks for the introduction, Matt. So my name is Tayser. I have been working on the Git experience or the source control experience inside the Visual Studio for about a year now. As Matt said, we are very excited to start to talk about some of the new features and functionalities that we have been working hard on. So this is a very fun and exciting time for us. Awesome. And Prateek. Hey, hey. Hi, everyone. My name is Prateek and I also work on the Visual Studio team along with Mads and Tayser. I joined the Git team, the version control team specifically with Tayser, a little bit later than he did a few months ago. I've been working on the Git features and super excited to revamp the entire Git experience in Visual Studio and add more GitHub integration features as well into Visual Studio to make your GitHub and Git experience super easy and convenient. Awesome. So that's really cool. I can't not notice, Prateek, that your home office, I presume your living room or something like that, it looks very much like one of those backgrounds from teams that you can inject is like that clean, white, perfect. Yeah. That was totally unintentional, but I do have a nice plant up here and it is a white background. I have to keep my blinds closed because otherwise there's too much glare. So there's always that problem, that white balance that I have to face. But hopefully it looks good. Yeah. I like their setup too. It looks more organic, more real. It's actually staged. I put up paper in the windows here to block some of the light, but I just got a new camera. So I used to have just the camera in my laptop. But what you were saying, the white balance and all this sort of stuff was just completely off, it couldn't handle it. So I got cheap no-name cameras because all the web cameras are sold out, like Amazon, Best Buy, you name it, anywhere. But there are still some of those no-name brands. So I got one and it's much, much better than what I had in just my laptop. So it's also wider. So you can see more of my messy garage. But yeah, that's how it is. So just a reminder to the people online right now who are live, we do have a Q&A panel. So if you look in your browser or in Microsoft Teams, you can see a Q&A is available. And so please ask any questions you've got to Tayshir and Pateek or myself about working with Git or GitHub within Visual Studio and or any other Visual Studio questions for that matter. We can probably answer a bunch of those too. So with that out of the way, I'm curious to know, let's start with you, Tayshir. What is some of the new stuff? What is it that you've been working on? Yeah, so we were, you know, at towards the end of last year, we, you know, we started to discover that actually the, you know, the previous experience that we had in or we had in Visual Studio was first of all, not very discoverable to lots of our Visual Studio users. So we would talk to folks and say, well, what do you think about the Git functionality inside of Visual Studio? And they'll say, you know, what good functionality, right? So that was a big aha moment for all of us here. So discoverability was a big thing. And then we got also a significant amount of feedback about user experience and the amount of clicks that is needed to execute specific functions, also having to switch between different pages to be able to follow a specific Git flow. So in Team Explorer, for example, we had changes, we had sync and then we have the branches pages and users had to jump between all of those pages to be able to do their day-to-day Git functionality. So like those were the two things that actually, you know, made us pause and take a step back and, you know, think about, you know, the new experience. And that is, you know, for example, one of the main new things that we have introduced is the top level Git menu. And that is really great because that enhances the discoverability of the Git features. And that is a great add-on for keyboard users now because using Alt-G, you can very quickly get to that menu and then access, you know, the different Git tooling or the different Git functionalities that we have, for example, right? Yeah, so that is one of the things that we added specifically to address that feedback. And then we added other features into the product also to address the user experience feedback that we got as well. For example, the Git tool window is an example there. It's a lightweight experience designed for the inner loop where you can very quickly, you know, code and then stage, commit, push your changes without introducing any context switching in that case. So let me just ask a question here. So I've heard people talking about the inner loop. I've heard that before. Like it's something that we talk about in Microsoft, but what is the inner loop and why? Like why does it matter and why do we care? What is it that we're talking about when we say inner loop? Yeah, so the inner loop is really important at the piece for, you know, because it is the flow that you go through on a daily basis as a developer, right? So any enhancements we introduce into that flow will end up, you know, with a bigger impact on your, you know, daily, weekly, monthly performance as a developer, right? And it is a goal for all of us here in Visual Studio to make sure that we focus on the inner loop to enhance the day-to-day experience for our developers, right? So when we talk about inner loop and Git specifically, we are talking about, you know, the steps that you, that a developer would need to do while they're coding, right? If you are fixing a bug or if you are working on a new feature. So in that case, you would need to, you know, write your code, start staging and then committing and pushing and doing all of those functions, right? So we consider those to be a part of your inner loop experience. Okay, well, that makes good sense. Yeah, but yeah, to add to that as well, navigation was a big pain point that we observed in users and that was affecting their inner loop as Tayser mentioned, you would have to navigate between different windows in Team Explorer and the other Git pages and version control pages that we had in Visual Studio and users complained about that, right? There was a big learning curve in understanding how to use Git functionality and it was taking away time from actually coding and developing, which is what we want developers to be focused on when they're using Visual Studio. So to simplify all of those experiences was one of our main goals and to streamline that into a single window that developers could use on the side and not get distracted from when they're actually coding and doing their day-to-day work. And this is supposed to be a very intuitive sort of add-on to that. All right, so this makes a lot of sense. So I assume that, you know, all you said that there was a lot of feedback from users about not being able to find the Git tooling, they didn't even know that we had Git tooling in Visual Studio, but that the tooling we also had was inefficient, was not good enough. And so I assume they just kind of didn't use it and instead used either the command line and I know that, you know, for instance, GitHub has like their own client 50 work on GitHub, you could use the desktop client or there are other products out there. Is that what people did? And then how did you then find out? How did you approach them and ask them about this? How do you know all this information, I guess, my question is? Yeah, so, yeah, so I guess the answer there, the short answer is yes, a good number of Visual Studio users relied on other Git tooling to do their Git work, including the command line and other visual tools like, you know, Git Kraken and GitHub desktop, as you mentioned, but we also had some Team Explorer users, right, that we kept talking to and get feedback from, right? So it has always been a combination of users using different tools for us, right? And sometimes when it comes to Git, our users tend to use, you know, a number of tools together. What was also interesting for us to see is that a number of our users were also relying on Visual Studio Code to do some of their Git work, which is something that we have noticed because, you know, they had Visual Studio Code had a lighter experience, which is a little bit more streamlined than what we had before. So is it fair to say that the approach you've taken is to maybe take the best bits of what was successful from Visual Code and the best bits of what was in GitHub desktop client or and take, you know, merge all those best parts into Visual Studio, how did you come up with what the right approach is? Well, not only that, Mad, it's not only the best bits, but because other tools also may have issues and problems that they don't know about and we need to discover and we need to kind of create a better tool. And this comes to like a part that I love doing as a program manager in Microsoft is we talk to customers, right? We talk to a lot of customers. We have a user experience lab back in Redmond when we all used to still work out of the office in Redmond, but in building 16, we have a great user experience level where we bring customers in developers of Visual Studio, developers who use other tools, very experienced developers, completely new developers who are just starting out in their careers. And we ask them questions. We sit them in front of us and we ask them questions about how they work, what they do, what makes sense to them, what doesn't make sense to them. We show them prototypes of our features. We show them working bits of stuff that we're just starting to work with and we ask them to like, you know, take steps and do tasks and we watch them observe them and we learn a lot from seeing them and not just the questions that they answer, but just, you know, the expressions that they make and kind of when they try to use a tool and are stuck and confused, you can really see that sense of frustration on their face and that's what we want to avoid and that's what we wanna help eliminate. And we learn a lot from these micro interactions that the customers have with these tools. Today in the climate that we have today we can't really go to the lab and bring users to the lab. So we do remote studies, right? We join teams calls with customers all throughout the day. We have some scheduled for today itself actually, right after this, we have customers coming and joining us on the call and we're gonna show them what we have in Visual Studio, the tooling in Visual Studio, as well as prototypes and mockups of new things that we're kind of working on and we get their feedback and we use this to kind of direct our vision and our designs, not just what other tools have and the best of other tools, but like new things that we can come up with and show to customers and users. Yeah, so to elaborate here a little bit, like what Pritik was trying to say here is that we are trying to build a first class get experience inside of Visual Studio by talking to customers and doing all of those activities that Pritik have been talking about. So that has been our goal to say here. Okay, so that's really cool. So you wanna build the best possible get experience inside of Visual Studio. So I guess that also assumes that, well, I will then assume that you are saying in a perfect world with no knowledge of what the constraints might have been architecturally and whatnot in Visual Studio, what is the pinnacle, the best possible get experience that we can provide to our users in their Visual Studio interloop, in their workflow and start from there. Is that how you started it or did you start more constraint and if you had those constraints, what would they be? Yeah, so that is actually a good point, right? So in our first user studies that we did, we discovered that there were, when it comes to get in general, there are two types of activities for users, right? Those interloop activities that users would need to do while they're coding. And there are those other activities that users don't, like they need to focus on, right? And when they are not actually coding, but when they are browsing, managing the repos, right? So the approach that we took here is to start by focusing on the interloop and then slowly expand into the other, richer, more focused get experiences that would require more real estate and require more interaction with users. Okay. So I've used Git for many years. I have like, I think 250 open source GitHub repositories. And, you know, one of the things that where I'm a little weird is I've always kind of been afraid of Git. I've always kind of been not wanting to do feature branches. I commit directly to master and I only have one branch. And that's been how I've been working all along. And so when I take a pull request, I take it and merge it straight into master. I don't rebase, I don't do any of that sort of stuff. If I get a pull request that needs to rebase because there's merge conflicts, I ask the pull request D to do that on their side before I can take it. That has worked okay for me, but I also know that it's a rather limiting thing because I don't do these feature branches. I don't have release branches. I'm missing out on a bunch of sort of automations I can do. I'm fully aware of that. But my fear has been just, you know, another merge conflict and another headache. Now I need to read up on like Git command line because I knew the Visual Studio tooling. But I guess I didn't know about it, but I felt like the Visual Studio tooling back then was not gonna help me in these advanced cases. So that was sort of where I came from. And I've been playing around with the newest Git tooling for the last, like a lot in the last couple of weeks, especially, but also a little bit before that. And I'm resolving merge conflicts now that, you know, I would never do that. I was afraid of that before. And now I'm just, I'm merging them. I'm doing feature branches. I'm doing all this sort of stuff. And I can't believe like if that has been possible the whole time that I've never done it before, but now you've wrapped it up in a, such an easy thing to do, right? It's such a pleasure to do. It feels natural. I don't have to guess on how to do things. I don't have to go read documentation on how to use Git command line or the Visual Studio tooling that you've built for me now. And so it's like a whole world opening up. And so first of all, thank you so much. But second of all, if anyone listening out there, you're in the same boat as me where you're not super confident using Git, try out the new tooling. So the Git top level menu that they're talking about, but also the tool window and all the features in there, that is just an absolute pleasure. So thank you so much. Is this available to everyone? Because I'm on internal builds. I get sort of the latest and greatest, you know, from our daily builds. We have like five daily builds and I get them all almost. So how do people get this? Can they do this today? Like if you're listening to us right now and you open Visual Studio, do you have it? Pratik? Yeah, sure. So the, well, it depends. The answer to your question is it depends. You may have it, you may not have it. We are right now in preview for the Git functionality. All this new, the new Git experience is in the preview channel of Visual Studio. So if you are, have downloaded and installed Visual Studio 2019 preview and are on the latest version of that. So 16.6 onwards, you will get this Git functionality. It is not yet in the release channel and we want to get there. We want to get there soon to be able to provide a complete Git experience to everyone using Visual Studio, the public version. And we want to get there soon, but we are, we're working hard. The entire team is working super hard to reach a point where we can say, yes, we're confident that all our customers, all our users, whatever they want to do with Git, they can do it in Visual Studio. They can do their inner loop. They can commit stage, stash, push, pull, make branches, solve merge conflicts. We want them to be able to do all of those core features within Visual Studio and we're slowly building that up. And while we build it up, we don't want to GA and say, hey, everyone use it in the public channel. We're slowly testing it out and making sure we're building the right experience with our preview channel customers. So if you are on Visual Studio preview, you can get this experience under a feature flag. So all you have to do is go to tools options and in environment, there is a preview features pane. And there you'll see all of the new, the latest features of Visual Studio that aren't available to the public directly yet. And all you have to do, there's a checkbox for new Git experience. And if you check that box, you'll switch from your old previous team explorer view of version control to this new Git experience view. The Git tool window will light up, the Git top level menu will light up and you'll be able to use these features. All right, that's awesome. I will say that before you rolled out this, I would say rather elaborate change. It's a big change. It feels big. It feels significant. There was one thing that I for many years asked for that never came, which was, I wanna have a keyboard shortcut to do a pull from, let's say, from Git up, let's say. So the typical scenario would be I would come into, I would open a repo that I haven't had open for quite a while. I knew that I've had taken pull requests for it or maybe I would not be sure if there were new pull requests that had come in in the meantime. And so I didn't know if I had the latest. So I would like to be able to, without opening Team Explorer at the time, this is before the Git tool window, the Team Explorer tool window, I had to like manually go in and say pull to get the latest or sync. And I would like that to be just a keyboard shortcut. And so what happened in visual through to 2019, I think the first version of 2019, so not even in an update, but correct me if I'm wrong, Taysher, I don't know if you were the one that did it, but I'm super happy that you made that into a command that I could find to a keyboard shortcut. And I could also, so I wrote an extension as well that automatically did it. So whenever you open a solution, it would automatically update all your branches. Like I think it did a fetch or something like that on your various branches that you've got. So you were always kind of at the tip when you started your day opening Visual Studio. And so that was like just a game changer for me. That meant that I didn't come to these situations where I had merge conflict, right? Because, oh, I forgot to do a pull and I just made a change and now I can't merge that thing in and all that sort of stuff. So this seemed this whole notion of like improving the Git tooling seems to have started, like actually quite a while back, this is not something new. Is that a correct assumption? Yeah, that is right. So some of the works has started some time ago, including what you mentioned. And I also know that there were some work that has been done on the stash functionality. Stash wasn't there before and that was added based on customer requests and feedback. So that's totally accurate. Yep. All right. So we got a questionnaire from Jerome. He says, I've been trying to use the new Git tooling but since the Team Explorer, that's the tool window Team Explorer is disabled and there's no show solutions and show folder view, I've disabled it. I'm frequently closing solutions and finding the active solution through the MRU is easy to work with. What is that? Is that something that you're looking into? What is that problem he's talking about here? So yeah, we have been getting a lot of feedback about the repos list and the solution list. Those were features in Team Explorer that we initially took out and that's why we started from kind of a methodology or a viewpoint of let's start simple. Let's not add on a whole bunch of features in the beginning but as we build up this Git experience let's start with the very simple basic features and as required we'll add on features and add on functionalities and capabilities where they make the most sense and if we get feedback from users that, oh, we were like the team in Visual Studio was not completely correct in the first assumption that this is not a necessary feature, right? And so their list of solutions and the list of repositories is something that we've been hearing feedback on from Team Explorer users to say that this is something that they're used to seeing and we do have some workarounds for that. So you can see your list of solutions once you've selected a repository and you can see your list of solutions in the MRU that you have in the start window in Visual Studio 2019. You can see your recent solutions that you've opened in the file, recent projects and solutions view. You can also, once you've opened up a folder in solution explorer, you can switch views to see your recent solutions in the folder view itself in solution explorer. So there are a few different ways where you can see your solution list within Visual Studio once you've selected a repository. So we do have those workarounds and we're trying to see if those are sufficient workarounds because I understand that it's completely a muscle memory and you kind of expect a design and once you're used to that design you kind of expect to see it there and switching to something new is always hard, right? Whenever an app that I use changes its UI I get like wait, where is everything? So it's definitely something that we want to help make easier and change management when we change UI on developers and users is always something that we're concerned about and looking for. So we don't want to rationally bring in a solution list anywhere, somewhere that may not make sense to the overall goal of the design and so we're trying to be very deliberate about how we bring features in. It's definitely, we definitely have an eye on it and these features that we're missing, please give feedback. You can go to our developer community where we have a lot of suggestion tickets and different features that users have requested. So if you go to aka.ms slash vsfeedback that's where you'll see all our suggestions and you can create a suggestion or even vote on the suggestions there and that helps us prioritize one of the most important things for you. Thanks for asking that. Yeah, that was a great question and a great answer. Thank you, Pratik. So it kind of illustrates a funny kind of thing about Visual Studio is that I've never myself, I've been using Visual Studio for like several decades and I've never used Team Explorer to open solutions. I've always used the file recent solutions in through there. I used to use the start page when we had that. Start window is also good. But it kind of illustrates like people just have different ways that are natural for them. And the funny thing is that oftentimes when we get suggestions coming in through the mechanisms that Pratik was just mentioning, people think that it's for them it might be the most important feature in the whole world and very few other people feel the same because they have a different workflow. And so it's actually hard for us to prioritize without a very large sample size of people to kind of figure out the priority of these different things. So I guess that's just sort of an anecdote to throw in there. But I guess that illustrates also why we don't have that solution view. The people that you talked to didn't have a strong opinion about having those out there but some people will just like Jerome that asked the question. So that's, this is fantastic. And this is why we do the preview features by the way such that we get to test it in the wild to get a much bigger sample size and broader set of feedback. So here's another question. This is from Larry. When will the Git global settings be integrated into the standard VS options? Teijer? Yeah, so actually that is working progress. That's a good question. So actually now we have the general settings already integrated into VS, VS's options. And we are working progress to finish the work on the repo settings, right? So that's definitely coming in. And an entry point to that would be, you know the top level Git menu and then you will have settings there. So if you click on settings that will take you automatically to that page. All right. Well, so that's good news Larry and everyone who wants that, it's coming. So Teijer, in the beginning you were talking about like discoverability problems that people didn't know that we had Git toolings. So for the people that did know that we had and used the Git tooling that was there did they ask for features that we already had but was kind of hard to find or they just for some reason didn't know we had like I think the office team had like some issues with that back in the day and that led to the ribbon to expose more of the features they already had. And was that the same case here for us? Oh yeah, absolutely. A good example that you mentioned today is the merge experience, right? We always had a great merge experience inside of Visual Studio. That is rich in functionality but few folks knew about that because an entry point to that was a little bit hidden wasn't very discoverable. So even though we had like we have started to enhance that experience actually but even before we started to do that like we started to get feedback from folks saying that wow, thank you guys this is a great merge this is a great new merge experience and we already had that before. So the work that we have been doing to enhance the discoverability helped and make it easier for folks to find the existing merge tooling that we already had into the product. And that is something that we started to focus more on and just to make sure that we keep enhancing it. So more and more enhancements are going to be coming and very soon for the merge resolution experience. Very cool. So I'm doing a lot of work with GitHub and I expect a lot of the viewers also work with GitHub repos on a regular basis. And so is there anything in the new tooling that's specific to GitHub? Because so far I think we just talked about Git in general and so any remote that supports Git will work including GitHub and others. But is there anything that's specific to GitHub? I think that's interesting now that GitHub is a Microsoft thing now. And so what do you got for us there? Yeah, so one thing we have there is the new init and push functionality where now very quickly with a single click you can not only initialize your local code but we do a bunch of steps for the user. So we initialize their local repo we create a new GitHub repository on their behalf and then we push their code into that repo. So once that's a significant shortcut that we introduced in that new feature and the feedback we have been getting so far is very positive there because like the previous workflow was if you already have code locally and you need to push that code to GitHub you would need to go manually to GitHub create your new repository there and then get the URL go back to your local repo and then add the remote and push your code. So lots of steps there to do for the user manually and we have automated that flow into end. So that is one example that we have been working on here. Yeah, and another example as well and I don't know how many people know of this feature or if it has been very discoverable is the ability to clone GitHub repository straight from Visual Studio. So you can not only clone a repository using a URL or an SSH format but you can also browse your GitHub repositories. If you've signed in to Visual Studio with a GitHub account on your key chain then when you go to clone a repository you can also browse through your GitHub repositories and it understands our authentication and just shows you a list of all the repositories that you have as well as your organization as under that one single list. You can also search different repositories, click on them and with a single click then that repository will be cloned down. So when you want to get started with code if it's either way you have existing code on GitHub and you want to bring that down or if you're starting with a new project and you want to push it to GitHub those are the flows that we started off with making super easy to get started and just to get started working with the code and we're going to start making more inner loop as we mentioned earlier actions in GitHub a lot more convenient and intuitive also. So that's on the roadmap. Sweet, so a lot more GitHub specific integration that sounds great. I'm a big GitHub fan myself and have been for many years even before the acquisition. So it's an authentic thank you, not a corporate thank you and so that's great. I've been using that to publish some GitHub repos and even though I could do that before with the GitHub extension for Visual Studio now it's all sort of within that same workflow of setting up your Git repository you immediately just go to GitHub and you don't even think twice about it. It just works fantastic. So has any of this been in collaboration with GitHub? Is there any like since we're now part of the same family is there a bigger push on like improving sort of the GitHub integration? How does all that work Tisha? Yeah, so we have, you know we started to work more closely with the GitHub team to enhance, you know our Git tooling instead of the product itself and there are, you know based on what Pritik has just said we are, you know there are still a lot to do there. So we are just, you know since we discovered that we had these issues discover abilities or experience and into our Git tooling and functionality we had to take this step back to rebuild or revamp the Git experience the basics in Visual Studio and then from there the plan is to continuously to add new features into it, right? A very popular example is the is the PolarQuest integration into Visual Studio. So that is something that we have started to work on last year and we had to close our work there for so that we can revamp the basics and then the plan is to get back to that, right? That is just an example that we have been working closely with GitHub for or on. Yeah, and as Tayser mentioned the GitHub extension for Visual Studio we've had some questions about like what's going to happen with that extension, right? If we're building functionality into Visual Studio and there are a lot of good features in that extension if you haven't tried it out you definitely should. There's the PolarQuest functionality there's forking and a lot of it we want to get into and inbuilt in Visual Studio but we're not there yet. So you can continue to use the GitHub extension and as we build more features in Visual Studio we'll try to create a fully functional GitHub experience inside of the product itself. Some of the other features are also like opening code from github.com. So if you have and we've been speaking with the GitHub team about this is if you're browsing github.com and you're on the browser and you want to open and you see a repo that you want to maybe clone down and start working on then you can with a click when you try to clone it instead of just cloning it and then having it flown down and then doing that maybe through the terminal or the command line and then you have to open the IDE or editor of your choice and then open find that repo and then open it in the IDE you can in a single click just open in Visual Studio so that will launch Visual Studio start the cloning the repository and it'll open it for you in the product itself. So that's also one of the features that's a great feature of the extension that is on our roadmap to get into Visual Studio as well. Yeah, I was just about to say we already did that like some years ago, right? There's if you have the extension and you've used it with GitHub then that menu item shows up on GitHub that you can clone with Visual Studio or open in Visual Studio. Open in Visual Studio, yeah. That's a feature of the extension and we worked extensively with the GitHub team in order to create that functionality it was a lot of collaboration between us and them and that was before the acquisition so that was pre-acquisition times itself. Okay, so are there any features that you already know now that you're not gonna do going forward like either features that the Visual Studio extension for GitHub already had or other features that maybe other clients have that you feel like they don't really belong in Visual Studio or something to that effect? Tejer? That is a very good question. We always think about the features that we miss. Yeah, and then we are actively working on this so we continuously focus on the user feedback so going back to what Pritik said earlier please, please, please continue to use the new functionality and provide your feedback, suggestions, we continuously monitor those. Actually, we have lots of good requests so our suggestions and feedback has always been full of things that it's not us not wanting to implement those, it's just prioritizing and figuring out where we should start. For example, very popular requests that we still haven't had the chance to get into is multi-label support but in order for us to be able to provide a great experience there we need to have a solid base first. So some of those suggestions and feedback we have been pausing the work on just to make sure that we are starting or have the right foot in to be able to build that functionality. And so we will continue to do our best to prioritize and figure out what makes sense implementation wise and from our users point of view to start to work on. Yeah, yeah, I'd say that nothing is thrown out or everything is game still. We haven't said that we're not gonna do anything yet. It's all a question of and it's a classic engineering problem you have a limited amount of time scope and effort that you can put into something. And so it's all about prioritization and that's why against suggestions and developer community and interacting with the entire developer community is super important for us to understand because we're gonna keep building and it's gonna be a long journey and we're gonna keep doing it as much as we have the time to. So the more you tell us as an audience and as our customers, the better we'll get it. Oh, that's fantastic to hear. So nothing's off the table, anything can happen. And basically the users guide the show, right? They make the suggestions, prioritize it, comment on it, vote on it. And that helps you prioritize and maybe get to things faster than you would have otherwise because you're realizing there's a priority over here that is now greater than this other thing you thought you were gonna work on. That's absolutely fantastic to hear. So are there any of those big ticket items that you are very excited to start working on that you don't have it yet but you're almost ready to start it and what would those features be? Is there a theme to them or is it like a little bit of everything? What do you got coming for us? Yeah, so that's an interesting question. So for example, one of the main feedback points that we have been getting into this new good functionality that we are introducing was on branch management. So on our tool window, we introduced a very lightweight branch management which is not up to the functionality that we used to have on Team Explorer before. So I'm happy to say that we are taking all of the feedback into consideration and that is one of the main things that we are starting to look into. And based on our studies before, actually branch management belongs to the focused experience, right? So right now we are starting to focus on like building that focused experience which is more of the, you can think of that as your repo management or you repo explorer. It's where you'll be able to do a rich branch management navigation. You'll be able to see a graph of your repo. So that is something that we are starting to look into and work on. So we are very, very excited to start to share bits and pieces there very soon. All right, that's cool. So branch management. So what does that mean? I can create branches, I can switch to branches or check out branches, I guess it's the right terminology. Delete, like is that sort of what you're talking about or what does it entail? Actually, we already have those lightweight functions that you mentioned as a part of our inner loop experience. So today you can very quickly create a new branch. We have different entry points. Their top level get menu is one. You can do that from the get tool window as well. So we already have that functionality but I'm talking about the richer experiences that we have been getting lots of requests on including the ability to delete multiple branches at the same time or the ability to visualize and look at your repo in a rich perspective or a rich way. And those things, we discovered that we need to build like a focused experience for. So that is going to be the base for all of these rich experiences, right? And as the more we build, the more functionalities we will be integrating there, richer experiences that users have been asking us for. And poor request is one of those experiences, right? For example, interactively base is another experience that we will be able to benefit by having that larger real estate to build and make sure that it is functional, it is usable, yeah. Sweet. So that's very interesting. The pull request thing you also mentioned here at the end, one of the problems I have with pull requests is I always, whenever I get a pull request, I always go to GitHub and look at it in the browser and it's, so that works okay. But it's not a very rich experience. And what I really like is to be able to actually just run the program with those changes from the pull request, maybe run the unit test, just make sure everything works, see it in action before I, before I merge that PR. And I don't really get that when I do it in the browser. And you know, so I will be the first to admit and I don't know if I'm alone in this, but I have merged pull request before that I kind of didn't know if they would fully work. I wasn't sure about the quality of them. This doesn't happen that rarely, to be quite honest. So is that something that you're gonna be able to help me out with so I can do like a more holistic view of that pull request in the full context of like it's running, the app is running, there's a database underneath, all that sort of stuff. Where are we with that? Yeah, so that is some of the stuff that we have started to work on last year and we had to pause, but then the plan is to make that a part of this focused experience, right? So we found out that, you know, it's really, when it comes to pull requests, you have two experiences. You have the author experience and you have the reviewer experience, right? So like we will look into those two experiences as soon as we are done with our basics. So for example, the author experience, Mads here, imagine that you have created a new pull request, right? And then you are waiting for feedback from your colleagues, right? So, you know, today we know that there is lots of context switching happening for the author, trying to switch between the browser and the editor or the IDE to basically bring in the feedback as they go through, you know, the feedback. So that's one thing. And then you also mentioned the reviewer experience is something that we looked at and we will continue to look at, which is basically about like making it easier to, you know, run the code pieces that you are reviewing into your IDE, which is something that you cannot do on a browser today. So those two experiences, you know, are things that we'll look at for sure. All right, so it sounds like they've already been on the drawing board and they will get back on and development will continue in the future at some point. So that's great to hear. So we are getting closer to the end here. So for those of you online, please ask any question you might have to Tasia and Pertig here. We also have a question. So the very first question we actually got in here was not about, it's not about Git or GitHub, but just the general revision studio question. So those are fine too, but that's why I haven't brought it up, but I will bring it up now. And then maybe get Tasia and Pertig's take on this question as well. So this is from, this is Martin. That's my old colleague from back in the day before I joined Microsoft, hello, Martin. He asks, when do you think developers will stop installing Resharper? Visual Studio has gotten a lot better and Resharper replaces or hides default functionality. So long time Resharper still think VIAs lacks a lot of features. That is a good question. What do you guys think? That's, I mean, it's a good question. Like discoverability is always an issue. And Resharper is one of our partners and it does have a, they do have a lot of great features and we do have a team, our .NET team, our C-Sharp team has been continuously working on adding more features that help a user in their development state when they're editing code and working on their applications. But yeah, we don't have a timeline we can't say if a developer is gonna actually stop when a developer wants to stop using Resharper, right? It's up to your preference and up to what you're used to and what you want to use. If you want to really see what Visual Studio is capable of, I'd suggest try turning it off for a bit. Like you can disable an extension pretty easily and see what Visual Studio has and try using it without Resharper for a little while and see what's missing still. And if that's really necessary for your development experience and the trade-off that you get of using Resharper and not using Resharper. So I'd just say give it a try and let us know what you think. Yeah, yeah, that's a good one. We hear from people all the time, you know, that they fall into camps, they tried to disabling it and some people like, whoa, I didn't know Visual Studio could do that. They haven't used Visual Studio without Resharper for like a decade. So they were not aware of what features are actually now in the product. And then you have the other hand, people that are like, hey, I don't want to use Visual Studio without Resharper. Those features are just super important. I tried to disable it and just didn't work for me. And, you know, there's no right answer. Like that's whatever makes you happen. And that goes for any extension. Like there's, I think there's over 4,000 extensions now for Visual Studio 2019 alone, over 10 or 11,000 for all of Visual Studio in the history of Visual Studio. So like they're there because they're personal preferences. And so we want to make sure that you're happy, you feel most productive. One thing we do know is that the more you personalize and customize your Visual Studio experience, the happier you are with Visual Studio. And so that includes extensions, includes settings that you set, your window layout, a whole bunch of things. This theme, maybe you customize your theme. Keyboard shortcuts, like you can customize those as well. So the more you tailor that to your workflow and to your personal preferences, the happier you are. And we know this because we've asked people a lot. So Resharper, no Resharper. As long as you're happy, we're happy. Here's another question. Let's see here is from Larry. Any plans on making it easier to see what changes that are to a function without multiple steps to open up and commit and then find the file compared to changes and then locate the feature in the compare? Like something similar to the peak help or peak definition? Yeah, so that's a good question. And we actually got some feedback on that. And we have been thinking about enhancing that experience. So the feedback we got there was, oh, I actually want to very quickly focus on a specific piece of code, a function or something and then be able to see what went with that function. Like go back and forth in history, but focused on that function, right? To see what happened, what is the history of that function and what might have introduced a bug or something. So that is something we are looking into. We still don't have a great answer for it, but we keep that into our backlog and we'll get to that as well. Oh man, that just sparks an idea. Like how cool would it be that if you want a method or even a line of code or on a method or on a class or on a whole file, you could just scroll back and forth in time. There's a slider. Go back in time and look through your commits. You can see who did what, what it used to look like in time. Is that sort of, is that sort of, I guess that's sort of the question here, right? Yeah, I'm just looking at, you know, we all seen movies where they build these, they program in 3D on multiple monitors and they already reported whatnot. It seems a little bit like that. Yeah, and that is the exact feedback we got, right? Like I want to get that rich experience that allows me to very quickly use that slider to go back and forth and see what happened there, right? And yeah, I mean, that is a part of the richer experience is that we are really looking forward into getting into as soon as we are done with our base, right? So we want to make sure that we have a strong solid base for functionality inside of the product. And then from there, we will start to look into integrating richer experiences. And that is just a good example there. All right, so we're kind of coming to an end here. I wonder if, before we hang up, do you have any closing remarks? Is there anything you want to tell the audience? Like what should they go do? What should they test? What is the one thing you want them to leave with here? They critique? Yeah, sure. And I kind of touched upon this before as well. For Visual Studio and the get experiences and for GitHub, our team is working to build up functionality and build up features. And we want to GA this, right? We want to GA this as soon as we can so that the entire Visual Studio developer community can use it. And right now, we're in a state where we think we're close and we think we're getting there, but the feature is still in preview and we want to get feedback from the developers from all the different kinds of developers, Madz, as you said, like every single developer has a unique way of doing something, of interacting with a feature. And we want to understand that we know that the way that we do stuff is not necessarily how other developers use Visual Studio. And we want to know if we're missing anything, if there is any critical features that are preventing us or that we should build out and prioritize before we actually GA this functionality to make sure that every developer and every kind of developer who uses Visual Studio can benefit from it. And so that's, I guess, my ask to the entire audience is to try it out, let us really know what's working and not working, and every single release we're adding new functionality to it. So if it's not working for you today, give us that feedback and switch it off if it's not working for you, but in the next release, try it again, turn it on and try it again because we've added more features and let us know then if what we've done has benefited and improved your experience in any way or not. So that's just my request to everybody, thanks. Awesome. Tejo, do you have anything? Yeah, I would like to add to what Pritik said. So basically, whether you are an existing Team Explorer user or whether you are a command line get user or whether you are using another tool, your feedback really matters to us. So please, please, please try the NuGet functionality and share your feedback. So we are trying to build something that is usable by all of our users. So we would like to make sure that we get that broad perspective. So please try the new feature, we are actively working on it, share your feedback and stay posted because we are continuously adding fixes, adding features, as Pritik mentioned. All right, well, thank you so much guys for coming on. This was super awesome. I'm a big fan of what you're doing. You're doing amazing work. So thank you. And I can't wait to see what is coming out in the next preview. So yeah. And so that concludes our fourth episode of our Visual Studio Remote Office Hours. We'll be back same time next week. So Thursday morning at 9 a.m. Pacific time. And as usual, we will tweet out links to the event so you can join live and ask Q&A. Thank you so much. And have a great day.