Before the SCM changes, staging selected lines would only stage the truly selected lines, since though it now seems to stage by hunks -- meaning if there are multiple lines changed together, as long as there is a selection range touching one of the lines, then the whole hunk is staged.
Steps to Reproduce:
Git: Stage Selected Ranges command@joaomoreno I can also look into so assign back to me if the solution is not on the top of your head
@eamodio I thought staging the entire blocks would be more useful.
@joaomoreno Often it is, but given that there is no other way currently to break up a "hunk" it makes it much less so when you need it. Honestly I'd be fine with the current behavior as long as there was another way to do it line by line.
IMO I SO wish there was little stage/unstage icons icons -- something similar to the current +/- on diff lines. But that also brings me to really wanting the ability to move "hunks" as well as lines from left to right in the diff view (similar to Beyond Compare).
@joaomoreno fyi - I think Beyond Compare handles this "hunk" vs line case nicely -- if your cursor is in a hunk and you "move" (to the other side) it, it moves the whole hunk, but if you have a selection it only moves the selected lines. To me that feels like a nice way to provide both scenarios for staging the hunk vs just selected lines.
Also because in vscode you can't really select the "deleted" (blank) lines in the diff view, it makes it harder to deal with staging/unstaging lines (and even just copying things from one side to the other).
Stage selected lines really is necessary. git add <file> -p is painful.
Just because two changes are on adjacent lines doesn't mean they're related.
I agree that Beyond Compare handles it nicely.
Perhaps a glyph that lets me add the hunk would work. At first, I thought that's what the plus signs were next to the line numbers. I thought those were commands to stage that line.
Yes... please revert back to the previous behaviour... The ability to only merge what is selected is great.
Staging more than what is selected is very counter-intuitive as it's hard to predict what exactly will be committed.
If you want to only deal with block, then I suggest you look at what XCode is doing. Their interface is awesome (the best I've seen of all tools).
It highlights the block changed and you can click on the + icon to stage the block. To unstage the block, you click and hold and select unstage.
But it doesn't allow to stage just the selection.
I wanted to open an issue about the current implementation of the git provider, cause it's hard to select ranges of deleted code to be staged. I found this, so I'll leave a comment here, but I'm not sure if this is related to 'the range are not selected correctly'.
Also, the functionality of 'stage line' would be awesome and it's really useful. Normally I use SourceTree for git commit manipulation, but I actually have managed pretty good with Code. Still, it have some missing things, like those two named.
@joaomoreno does that commit allows for select deleted lines or should I open a issue just for that?
@michaeljota A request for that is open here: https://github.com/Microsoft/vscode/issues/9475
Thanks @eamodio
Most helpful comment
Yes... please revert back to the previous behaviour... The ability to only merge what is selected is great.
Staging more than what is selected is very counter-intuitive as it's hard to predict what exactly will be committed.
If you want to only deal with block, then I suggest you look at what XCode is doing. Their interface is awesome (the best I've seen of all tools).
It highlights the block changed and you can click on the + icon to stage the block. To unstage the block, you click and hold and select unstage.
But it doesn't allow to stage just the selection.