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: https://github.com/microsoft/vscode/issues/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

Em dom, 12 12e jul 12e 2020 às 12:11, João Moreno

escreveu:

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".

[gjsjohnmurray]

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

@stagefright5 AFAIK the "new release" label gets added automatically by a bot if an issue's description contains the version number (e.g. was created from the Report Issue option of the Help menu) and that version was recently released. I don't think adding the tag manually to this issue will achieve anything. @joaomoreno has already assigned it to the next milestone.

[gjsjohnmurray]

@joaomoreno maybe the SCM view's tree could be made to behave like an accordion, so when a first-level item expands the previously-expanded first-level item gets automatically collapsed.

[GilShoshan94]

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.

Totally agree, please add a setting to use the old view.

[danielb42]

Let's emphasize that this is not just about whether one likes the new view or not, or whether it can be accepted as an yet unpolished step towards another design goal - it is a clear regression in terms of single-repo usage. Working on a single folder now requires the user to pull/push out of the context menu (yuck), the status bar (if enabled), command palette, shell, or even third party extension. I don't want to get even more creative here, I just can't think of any sane reason the sync buttons were intentionally removed from single-repo view.

[joaomoreno]

it is a clear regression in terms of single-repo usage. Working on a single folder now requires the user to pull/push out of the context menu (yuck), the status bar (if enabled), command palette, shell, or even third party extension. I don't want to get even more creative here, I just can't think of any sane reason the sync buttons were intentionally removed from single-repo view.

There will be a setting to show the repository row, even in single repository view: #102080. The reason why it's not shown by default is that those actions are all in the status bar. Sure, you can always disable the status bar, but most users don't. The sync buttons weren't intentionally removed from the single-repo view, since the SCM providers view wasn't visible by default, maybe you enabled it to always be visible?

[danielb42]

@joaomoreno Oh, well indeed it was custom-set scm.alwaysShowProviders that enabled the single-repo view with buttons I was referring to. Thanks for clearing up that my pain comes from the removal of that setting, not so much from unified view of 1.47. ;) Looking forward to results of #102080.

// I still agree with all and any critique concerning the specific design decisions of the view in this thread though. ;)

[astrowonk]

I just think it was a mistake to change the UI this much, especially the multiple text entry fields for commit messages and moving the relative position of the commit message text field, per @igoramadas's comment.

I don't particularly understand the use case of moving the view to the panel,etc. (was this a feature request that a lot of people had?) but if that's desired, then just recreate the previous UI-positioning where the relative position of the most common actions (i.e. typing in a commit message and committing) are the same:

There should only be one commit message text entry field visible at a time and it should be below everything else. Until that is possible, please just let us use the old non-relocatable, non-single view.

[mdwagner]

I think this https://github.com/microsoft/vscode/issues/101112#issuecomment-650178257 showcases the differences better, but I still prefer the old view even after seeing a side-by-side.

[karolpiczak]

One thing I also miss when compared to the old setup is fast switching between multiple open repositories with long lists of active changes. Now it requires either a lot of scrolling or "collapse all" -> click on a specific row, so it's two clicks instead of one. Plus we've lost the ability to get an overview of repo status when scrolling big lists.

[gjsjohnmurray]

Plus we've lost the ability to get an overview of repo status when scrolling big lists.

@karolpiczak did you try changing the scm.providerCountBadge setting?

[karolpiczak]

Yes, but this does not influence the list scrolling thing, e.g.:

In this case it's much harder to reach control buttons when scrolling through such long lists.

[gejiawen]

Maybe a feature toggle is indeed. BTW, I like the old style, smooth to control all my repos.

[HanBnrd]

Hello 🙂

I think the ability to see changes only in one repository at a time was very convenient and I regret it's now gone... The problem I find with the single view is that, as the number of files with changes always varies, the user always have to visually search for the commit message input field which is never at the same position. Moreover, the file names get mixed up with repository names (with only the font weight to distinguish them).

The ability to have the list of repositories at the top with the commit message input field just below makes it easier to find with visual memory. Could you please bring this option back?

[m50]

The issues with the SCM single view, with misleading indentation, plus the lack of spacing between everything, with no clear visible separation has made it impossible for me to use the VCS feature in VSCode's latest update.

It's an accessibility nightmare for those who have reading disorders, where without proper spacing, letters get jumbled. Even for those without reading disorders, like me, it can still look like a letter and symbol soup. There doesn't appear (at least that I found) to change the background color or spacing of the titles, so it's completely unusable.

The earlier version allowed me to just look at one section at a time, having a separation between the providers and the actual commit section. This was plenty usable, and quite a lot better accessibility wise (at least for reading issues).

I've had to revert my VSCode version specifically because of this issue.

[smikitky]

I also have a workspace containing lots of repositories that are related to one another. The new version is really hard to use in this situation. If this is not revertible, I have two suggestions.

• Could you fix the layout to clearly indicate repository boundaries? Due to the bad indentation, it's currently hard to tell a particular line is a repository name or a changed file.

  

  Why are the right arrows (＞) hidden for "example1" and "example3"? Because of that, to my eyes, it almost looks like they belonged to the "Changes" of the example2 repo.

• Could you introduce a setting to lower or temporarily hide repositories that are up-to-date and have no changes? Currently, my source control view is occupied with many repository names that are not immediately important. ("Sort by status" doesn't seem to do this.)

[stackh34p]

I have tried to switch back to version 1.46.1, but I seem to be unable to prevent VSCode auto-update (see https://github.com/microsoft/vscode/issues/102666). Does any of you guys experience the same issue?

Maybe I should switch to an earlier version, as I am caught in an downgrade-upgrade loop.

[Somberland]

anyone else got extreme performance-problems since the new scm? staging/unstaging changes takes sometimes ages :/

https://imgur.com/a/bKzgtec

[danieltodor]

+1 please change it back. I had to switch back to 1.46 because of this. The new view makes it inconvenient to use the scm. I can't imagine a situation where the new view has any advantage over the old one.

[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 https://github.com/microsoft/vscode/issues/101103#issuecomment-659773364 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.