SCM: Single view feedback

[astrowonk]

I do not like the new look of the source control. In the old system, if I had 4-5 repos showing, the one or two with active changes would show up clearly at the bottom. Now it's very muddled, and sort by status simply puts the repos with changes at the top. Maybe allow for sorting such that changes show up at the bottom where there is plenty of null space, not at the top surrounded by other repos and text/widgets.

Repos with changes should stand out and be separated from other nominal repos. The current sytsem doesn't do that.

[remedix]

I have to minimize repos by clicking on tiny buttons

@remedix without wanting to sound like I'm endorsing all aspects of this change, did you try using the Collapse All Providers button at the top of the view? Then when you click anywhere on a provider header it will expand. No need to aim for the twistie.

Or if you are focused anywhere on the tree use the standard Ctrl/Cmd+LeftArrow to collapse all.

Yes it is in my daily workflow as well. I have to do this 'dance' everytime to filter out the clutter. This might be just the way i am used to work but from the comments above I think other people aren't really fond of the change.

I understand that this featured was probably discussed and agreed upon but I still believe this is something that users should choose how to use it - at least offer customizations.

[nbeentjes]

@gjsjohnmurray

The difference between the repo-level count (5) and the Staged Changes count (4) tells me that some changes will remain after I commit what I have staged. I think that might be of use when you have a lot of changes and the “Changes” moves out of view, else the two categories already show if there are still remaining changes you have not staged (even when “Changes” has been collapsed).

The problem I have is that when you have multiple repositories with changes (staged and/or unstaged) you end up with quite a list of count badges that are fighting for your attention. What if it simply shows a grand total, like 4/5, or just the number of changes to go? That could also work with other SCMs.

[a-h-abid]

+1 on reverting to the old way to deal with multiple repos in single window.. Current way too much confusing !!

[pytheous]

Ok. not to continue to pile on, but i just moved the SCM window into the output window (to see why moving it would be useful... it was not) and then moved it back.. now the icon is messed up and looks like a terminal window and not the SCM icon. I am seriously baffled why this team would push code that is obviously untested by even a marginal swath of the community.

I must also reiterate that I HATE that I cannot see the name of my repo in the SCM screen. or ANYWHERE else on the screen without having to hover my mouse over the branch in the bottom left of my screen, which is very annoying and will simply never happen. Ill change IDE's' before I do that.

[gjsjohnmurray]

now the icon is messed up and looks like a terminal window and not the SCM icon.

102262 and listed fixed in Insiders.

[astrowonk]

So are we just going to have to live with the new view @joaomoreno ? I don't see anything about it in #102174, we're up to 1.47.2 and no option to use the old view has been restored.

This isn't a minor nuisance for us, like the new view is causing people to make wrong commits and thus stay on 1.46. I don't want to stay on 1.46 forever but that's what I'm looking at right now. What's the plan? Can we please have a toggle to use the old view until the new UI is further refined?

[smaranh]

+1 The comment above. Please provide a way to revert back to the old view in SCM.

[ninlil]

+1 on preferring the old UI, also to the "visual memory" situation.

Some more details:

• The "Provider Count Badge" appears at the right of the "branchname & tools", thus moving those tools around which is not a good thing (UX: "don't move action-items based on content changes") -> Place it either after the Repo Name instead or before the "branchname & tools"-part
• Lacking "visual memory support"; make the repos sortable (alphabetical), including manual ordering. This makes it easy for a user that knows a certain repo is near the middle to start scanning with their eyes there instead of searching the entire list.
• Provide path-information: On hover over a repo-name, please display the actual path
• Detect git sub-modules, and display which parent repo they belong to.

And last but actually most important:

• Add settings to the layout to allow users to select what parts to display and where to display them.

[justinian-tomegea]

Source control repository name is fugly and it doesn't fit the explorer view style.

Add settings to customise the font family, font size and weight.

[dalgarin]

+1 to the new SCM Single View feature being a step backwards. The old way of allowing a repository to be selected and displaying commit/stage/changes for only that repository was much cleaner. New single view is confusing and makes it difficult to keep changes straight between repos in multi-repo workspaces. Will be reverting to previous version.

[bokubeam]

Reverting as well. This was a major feature of using multi-repos in vscode for me, and this new version is far worse when working with a large amount of repos.

[joaomoreno]

What's the plan?

The plan is to take the feedback and keep iterating forward, fixing the issues with the current solution. I will distill the feedback from this issue and come up with individual items to address.

[astrowonk]

What's the plan?

The plan is to take the feedback and keep iterating forward, fixing the issues with the current solution. I will distill the feedback from this issue and come up with individual items to address.

I meant more what is the time frame, because there are other non-UI SCM issues in the iteration plan, but not anything about the multi-repo problems have have expounded upon here, which I guess means it'll wait for 1.48 or later?

I feel like we have given very precise feedback with screenshots of why the new UI is a regression, and why it's confusing, and instead of giving us the option to use the old UI, or quickly fix some of the problems of the new one (i.e. the confusing multiple commit text entry fields instead of a single commit text window at the bottom), we've heard mostly silence - I have not read any posts about planned solutions.

I guess a lot of us will be using 1.46 indefinitely.

[stackh34p]

I do not want to disrespect the work developers of vscode are doing, but in my own experience as a software developer we have striven to do the following:

• We try our best not to release UI changes that are confusing and provide worse UX
• If we accidentally do, we patch our software with the latest working UI to migitate UX issues further and reduce user frustration
• We continue to work on the new UX in the background and eventually release it when we have addressed most of the issues and the thing becomes usable. Insider programs, and extended testing audiences of the kind are a welcome target for such unreleased changes while we polish things

From the vscode developmet team I have not seen any indication they are following the above pattern, which does not mean that they don't intend to do this, but have communicated the intention poorly.

The bottom line here is that users should never be cut off from the latest changes, which could include security vulnerability patches and performance improvements, besides UX changes. The latter is obviously less significant in importance and should not be a reason for people to keep using old and less-effective versions of a software.

I'd justify enforcing UX changes when the new UI is usable and stable, but vscode devs here are seemingly being too stubborn to revert a bad UI decision -- ignorance to the community wishes is not a good way to do open-source software. The bad UX of the new SCM view is not the only issue. I do not want to be using 1.46 for the forseable future because of someone being stubborn to revert a UI change. It is not very easy to set up a number of development machines with old versions, the download-and-install experience is horrible compared to just getting the latest download link, you also need to fight with the auto-updater (which is ON by default) after installing the old version in order to stay with it.

[joaomoreno]

Hi all, thanks for the feedback, we do hear you loud and clear. 👍

I've spawned a new issue which I want to tackle early next week: https://github.com/microsoft/vscode/issues/104151 This will bring back the parent/child relationship that we're all used to before, but instead of going back to individual view panes, it will simply manage visibility of the current pane. This addresses most of the current pains and keeps the vision of a single changes view possible. Unfortunately we are currently in endgame and I can't make this happen for July, which means it won't make stable until the end of August, but it will land Insiders as soon as the code is pushed, so feel free to subscribe to it if you want to get notified. After that, we'll keep on iterating on the UX within each view to keep making improvements.

Thanks for your patience and your passion for the product, it really makes us work harder. 💪