Git Line-staging Released!
Taysser Gherfal
We are excited to announce the release of Line-staging support in Visual Studio 2022. Line-staging, a.k.a. interactive staging, enables you to split your changed lines of code across different commits. Line-staging could also be utilized in reviewing your changes before committing them. Mark your changed lines or sections of code as reviewed by staging them and commit your staged changes when you are done.
Start using Line-staging by updating your Visual Studio 2022 to version 17.3 or later.
Read our Line-staging documentation to learn more about how to use and customize this feature.
Other relevant blog posts
- Line-staging (Interactive Staging) – Visual Studio Blog (microsoft.com)
- VS2022 Performance Enhancements: Git Branch Switching – Visual Studio Blog (microsoft.com)
- Introducing new Git features to Visual Studio 2022 – Visual Studio Blog (microsoft.com)
Let us know what you think
We have benefitted greatly from all the rich feedback we’ve received from you – thank you! We hope you’ll help us continue to improve by giving the new Line-staging support a try and letting us know what you think by taking the following quick survey:
Light
Dark
14 comments
I must be missing something, because I’ve been using Git Diff Margin extension for some of this functionality until now so I turned off “Track changes” in Text Editor > General, but I can’t see these markings in the margin.
I checked “Show the difference overview margin” in Advanced, and “Enable line staging support” in Preview Features.
Thanks for the feedback! What version of Visual Studio are you on Tsahi?
17.3
I can see the line staging margin in a diff window, but not in the normal editing window.
update: now it works in the editor too (v17.3.1). Could be the check in Text Editor > General > Track changes
Please remove the aggressive mouse-over that requests you to “Stage change” + “Stage lines” + etc. when viewing differences.
99 pct. of the time then I’m not interested in doing staging of individual changes, but just want to view the differences.
It generates a lot of screen noise and distracts you from the task at hand.
As a developer then I do not want to be bothered with unwanted popups and noise.
Indeed, after using it a couple of weeks, I have had exactly the same feeling.
Thanks for the feedback, Rolf and Martin,
To clarify, do you find this annoying on the full screen Diff experience or on the new Peek Diff experience? Just trying to better understand how you have been using this feature. Thanks!
Sorry to say but literally annoying. I use a 1080 monitor 16inch and when ever i want to click at the end of screen on a particular line to take cursor towards right i end up with staging it or undoing it. Not sure how many users asked this feature but its not a cool feature. At least disable it by default.
Absolutely agree.
It’s really annoying… it just gets in the way.
I never want this functionality, and I have accidentally clicked on it many times.
I don’t like aggressive mouse-over-popups. Period. But I’m mostly using the full screen differences, so it very annoying for me there.
I try to stay away from any of the peek-window-features, since it again distracts me from the task at hand, and the code that I’m currently working on. If I need to navigate to new code, then I will open that code in a new window, since reading code in a small window with 8-10 lines is a horrible experience for me.
I sometimes use the diff to do review of my changes, sometimes I use it to do minor editing. Often when I want to put my cursor at the end of a line, the line all of a sudden is staged.
If only the popup would not be over the line that you are trying to edit. This is the most frustrating thing ever!
Staging changes line-by-line doesn’t seem like something that should be encouraged. If you’re not staging the whole file, that means you’re (probably) not running tests against the actual code being committed.
Line-by-line revert seems pretty cool, though!
I disagree. It only means you have two or more commits for the changes at hand, as if you made an edit and committed, and then made another edit and committed.
Of course, you have to make sure your partial commit compiles, i.e. that the chunks are unrelated.
This is really nice! But a few things that are holding me back from fully embracing it.
What if if we still want to see the highlights after we have staged the changes? I find that very useful in Git Diff Margin. Also, if we create a new file that has not yet been committed, it should be indicated as new as well (also done by Git Diff Margin).
Thanks!
Ernie