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.

[astrowonk]

The new "unified" view is so cluttered I reverted to 1.46. Yikes. There is a ton of vertical space. Put "changes" all down at the bottom underneath everything else, not something i have to seek amongst 10 other nearly-identical looking text fields.

[mdwagner]

I think what's happened here, is that there were 2 different ways to view your repos in SCM:

• where you select one repo at a time
• where you select multiple repos at a time

I guess it was decided(?) that they should only have one way to do it, but I dont think it was taken into account how many people used it the other way. I myself used it the single repo at a time, with all changes at the bottom; I was never a fan of the multiple repos view, which seems to be the default now.
(Note: for the time being, I'm going back to git cli, since the visual tools were just a nice-to-have for me)

Maybe someone else can comment on this decision?

[gjsjohnmurray]

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

The scm.providerCountBadge setting may help with this.

[astrowonk]

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

The scm.providerCountBadge setting may help with this.

Doesn’t really solve the problem of the change/commit message text crowded amidst the text of other repo names instead of separated / detached at the bottom.

[fernandopsilveira]

This is a regression! I work with source repos selection a lot because it makes it easier to see what I want/need per workspace. Now I lost that feature 😞

[FRAGGYnz]

I'm trying to like this new change but it's hindering my workflow,

I also used the Source Control in a "Select one repo at a time" way, now i've got too much clutter taking up un-necessary space.

I'm also going back to 1.46 until a better single repo at a time view can be put back in

[astrowonk]

Here is the old view. List of changed files only show up when a repo is clicked. They are clear and distinct, separated from all the list of repos and everything else at the bottom.

The new single source view. One has to hunt for the changes amidst a list of other repos. It is cluttered, hard to parse, and requires hunting to find what you want. The old view was much easier to follow and use.

[igoramadas]

+1 to this. Would be great if we could switch the SCM view (old or new style) with a feature toggle.

I find the new view is very cluttered and I'm constantly mixing up and writing the commit message on the wrong input field :-(

[stackh34p]

I will revert to the previous version until this feature gets a fix. I use a workspace with a lot of separate projects in it. I love the speed of VSCode and that I am able to seamlessly manage multiple projects. However, it has become a pain with this change. I am not sure what usability improvements you sought in applying this change, nevertheless you should have probably asked the community before doing this in an irreversible way. At least make it possible to switch between the different modes.

[stagefright5]

It feels like engineers never got to test this "feature" outside of some of the dummy projects, outside their bubble and thought to themselves that it will work with real projects too.
I am extremely curious as to what were the UX elements that they were thinking, this would improve. What was the thought process behind this.

Because of this, I have now started using insiders build, so that I can provide early feedbacks.

[gjsjohnmurray]

@stagefright5 As I understand it (I'm not part of the team) a big driver of the re-engineering of the SCM view was the need to make it a single view that could be moved to other places in the UI. See #101302.

Using Insiders is a good way of contributing feedback about changes before they get baked in.

[joaomoreno]

From @stagefright5:

I would say that new UI for SCM is worse. Some pain points:

• Users have to scroll to see the changes in a particular repo. Scrolling to find anything is very hard. always.
• Users have to scroll to perform any action (Write commit message, stage, commit etc)
• Users have to collapse each and every repo's changes to see all the repos in the current workspace.
• New UI is very clumsy as the repo title and changes are combined and only way to differentiate them is by their font-weight
• It has become way harder to see the number of changes as the action icons in front of each branch now require us to sacrifice the editor space to see them
• Because of the the new "commit" icon, the repo name and/or the branch name is hidden
• The branch info such as number of un-pushed commits, un-pulled changes, whether the current branch has been published or not, etc. are not visible now. (I know, there is status bar. But, it is an extra step to remember to look at the status bar)

Additionally, it causes this issue also: #102079

This UI, according to the release notes, is supposed to be more flexible in terms of moving views. But, IMO, these cons outweigh this.

I would request to at least keep this view as optional and let us switch between the new - old UI, while the team works on improving the new UI.

[astrowonk]

@stagefright5 As I understand it (I'm not part of the team) a big driver of the re-engineering of the SCM view was the need to make it a single view that could be moved to other places in the UI. See #101302.

Using Insiders is a good way of contributing feedback about changes before they get baked in.

Yeah, I read this - I'm honestly not even sure what moving the UI means or why anyone would want that. This lets us move the SCM view out of the SCM view? Where else would we want to put it?

[joaomoreno]

Hi all, thanks for all the feedback! As @gjsjohnmurray mentioned, Insiders is a great way to give us feedback before stuff makes it into stable.

This new way of interacting with SCM is still being polished but we decided to push it forward since all the functionality is there. It also aligns with the flexible view layout we've been working on for months now. There are definitely a lot of issues we can start ironing out, so please the feedback coming, we really appreciate it!

[fernandopsilveira]

Feedback was given!  Please provide a way to get back to the old UI, at least until the new single UI is polished enough to not generate so many complaints <div>Em dom, 12 12e jul 12e 2020 às 12:11, João Moreno</div><div><[email protected]> escreveu:</div> Hi all, thanks for all the feedback! As @gjsjohnmurray mentioned, Insiders is a great way to give us feedback before stuff makes it into stable. This new way of interacting with SCM is still being polished but we decided to push it forward since all the functionality is there. It also aligns with the flexible view layout we've been working on for months now. There are definitely a lot of issues we can start ironing out, so please the feedback coming, we really appreciate it! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[gjsjohnmurray]

I'm honestly not even sure what moving the UI means or why anyone would want that. This lets us move the SCM view out of the SCM view? Where else would we want to put it?

@astrowonk if/when in due course they give us two sidebars (one on the left, one on the right) you might like to move the SCM view across. As a result of the 1.47 change you can already move it to the Panel. Or combine it with the Timeline view.

[igoramadas]

Pardon my ignorance, but wouldn't it be possible to align it with the flexible view layout but keeping the previous UI (keeping the list of SCM repos on top, and displaying whatever is selected below)?

My pain point:

File settings.json from repo "core" is highlighted so I see the diff, and I want to add the commit message. There's not much separation to the next repo, "web", and it's very easy to glance to the wrong input field (in this case, from "web" instead of "core"). Result is a commit on the wrong repo.

That has happened at least 5 times today. I'm trying hard to train my brain to glance up and not down for the correct input field, with no success.

I completely stopped working with multi-repo workspaces and I'm now resorting to multiple windows instead because of this :-(

[astrowonk]

File settings.json from repo "core" is highlighted so I see the diff, and I want to add the commit message. There's not much separation to the next repo, "web", and it's very easy to glance to the wrong input field (in this case, from "web" instead of "core"). Result is a commit on the wrong repo.

That has happened at least 5 times today. I'm trying hard to train my brain to glance up and not down for the correct input field, with no success.

All of this. The input fields floating up there amidst everything is a mess. One input field for a commit message at the bottom for a selected repo, just as it is today. That's really the key UI problem here. I'm staying on 1.46 until this is resolved.

[astrowonk]

Hi all, thanks for all the feedback! As @gjsjohnmurray mentioned, Insiders is a great way to give us feedback before stuff makes it into stable.

This new way of interacting with SCM is still being polished but we decided to push it forward since all the functionality is there. It also aligns with the flexible view layout we've been working on for months now. There are definitely a lot of issues we can start ironing out, so please the feedback coming, we really appreciate it!

Please revert or let users revert to the old way. The new UI is really not ready for release, and per @igoramadas 's comments, can lead to making the wrong commit. I don't want to stay on 1.46 but that's the only option for me for now.

[gjsjohnmurray]

@igoramadas it sounds like you have enabled Smart Commit, so you don't manually stage your changes first, right?

[igoramadas]

@igoramadas it sounds like you have enabled Smart Commit, so you don't manually stage your changes first, right?

I have, but half of the time I'm manually staging changes as well:

Here I can't even see the the correct input box for the commit message. The one below, for the wrong repo, has a magnetic effect to my eyes.

[gjsjohnmurray]

As a workaround maybe start by clicking the "Collapse All" button at the top, then expand the repo you want to work with.

[stagefright5]

Just wondering why is this not labeled as "new release".

[nbeentjes]

File settings.json from repo "core" is highlighted so I see the diff, and I want to add the commit message. There's not much separation to the next repo, "web", and it's very easy to glance to the wrong input field (in this case, from "web" instead of "core"). Result is a commit on the wrong repo.

That has happened at least 5 times today. I'm trying hard to train my brain to glance up and not down for the correct input field, with no success.

That’s exactly the issue I had with the old SCM view. I had to make sure to look at the top to see if I had selected the correct repo, especially when filenames in some repos are very similar. The new view stops me from doing that, however it doesn’t really make things that much better either. Due to the enormous density of all the items it is almost impossible to distinct staged and unstaged items. So now I am making many commits that have me puzzled as to why they aren’t being added. Another good look shows that I didn’t stage the files yet. Not to mention you now can’t see the entire branch name (not very nice if you use feature/ and such; I did find that moving the SCM to the panel (where the terminal is) to workaround that for now). This is already covered in #102081

Going back to the old version might solve some issues for some people but it is going to cause issues for others. Having the option to switch between the two views would indeed be very nice but it would be even nicer if Microsoft would continue working on the new view and do something about the enormous density and cluttering it causes. There needs to be more separation of certain items (more identation, more space between repos, etc.) and perhaps some grouping to make it more clear that certain items belong together (i.e. grouping per repo).

Meanwhile it seems doing source code management on the commandline is a good workaround. It doesn’t overload you with heaps of information so it is a lot more clear.

[gjsjohnmurray]

For those here who want/need clearer visual separation between the provider header and the files that may appear above it, you may like to see an experiment I did at #101103 (comment) which moved the provider count badge (scm.providerCountBadge) to the left and also increased indents slightly. Anyone else feel the option of top-level badges on the left could be part of the resolution to this UX issue?

[nbeentjes]

Not really. You are adding yet another piece of information, there already is a badge next to the “Changes“ header, and it offsets the list of repositories a bit. I think the added indents help heaps, just too bad that they also affect the Explorer (I feel it is right in SCM but too much in Explorer).

[atlanteh]

For me, it would be great if there was an option to hide repos without any file changes, as I have a workspace with many repo's, but usually I only work on 2-3 at a time.
Though, I usually commit and push the code from the terminal.. So this setup might prevent people from using the push functionality as the repo will be hidden..
Another solution might be to hide repos without file changes AND are on master (or another default branch)

[gjsjohnmurray]

@nbeentjes yes a repo-level count badge may be superfluous when the repo is expanded. But if you have multiple repos in the view and have used the Collapse All button in the view title then the counts tell you where the changes are.

For the mockup I tweaked the spacings directly via Developer Tools. I agree the extra indentation should be SCM-tree-specific. Perhaps @joaomoreno can override the setting (which defaults to 8) and use max(16,workbench.tree.indent). Perhaps only do this for the first two levels, so as not to affect tree-view of changed files.

[nbeentjes]

@gjsjohnmurray it could be merged: just show the count badge behind or in front of the repo (whichever you fancy). Not sure if the count badge is all that useful for the changed and staged items. What if the count badge shows up when the repo is collapsed and disappears when it is not?

[gjsjohnmurray]

What if the count badge shows up when the repo is collapsed and disappears when it is not?

@nbeentjes yes, that idea occurred to me too. But here's a case where having the repo count visible even when expanded gives me information:

I have staged enough of my changes to push the Changes folder and its badge out of sight. (Achieved here by giving my window an unrealistically small height). 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.

[remedix]

+1 Please provide a way to switch to the 'old' view as this is as clustered as everybody else is saying. Having 10 repos at any given time with multiple staged and unstaged changes makes this really clustered. I have to minimize repos by clicking on tiny buttons to get a clear view of what i'm currently working on. Please review this

[gjsjohnmurray]

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.

[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: #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. 💪