Explore UI additions to help guide users to push to a remote after committing

[eamodio]

Here is the first (rough) pass at exploring the addition of unpublished commits / unpublished changes in the SCM view.

The ordering of the groups is unlikely to stay as it, but still exploring alternative options (commits on top, then staged, then changes vs changes on top, then staged, then commits).

Also quite unsure of the toggle between commits vs changes. Commits honestly feel a little "off" in this UI because it is all about file changes, but just having the unpublished changes, hides important information about the commits.

Very open to thoughts and feedback!

[MarcoZehe]

Could you verbalize the intended/proposed workflow? Without being able to see them, it is difficult to comment. I recently started using these features and might have thoughts, bbut I'm blind.

[mrvkino]

As mentioned by @MarcoZehe an explanation of the intent would help steer the discussion.

In the meantime here is my 2 cents.

I think logically the commit section should be the at the top since it follows the logic of higher is closer to the server. Since we can collapse the commit section, this should not bother people too much. Also, it helps with the objective to make it clear that some commit have to be pushed.

The complete state change for the commit section, shown in the gif, was a bit jarring for me. It took me a couple cycle to understand what was happening.
For viewing the change in a commit, I would prefer if the files would be listed under the commit when expanded (like a folder with sub-file and sub-folder). It would look like the changes section, but nested under a commit.

[gjsjohnmurray]

For viewing the change in a commit, I would prefer if the files would be listed under the commit when expanded (like a folder with sub-file and sub-folder). It would look like the changes section, but nested under a commit.

This could probably be achieved by adding a new resourceGroups: SourceControlResourceGroup[] property on SourceControlResourceGroup. I would find that useful for my own source control extension.

[eamodio]

After a lot of internal discussions and many mock ups, we've settled on a simpler design below:

There are 2 main changes

1. The existing scm.alwaysShowRepositories setting is now turned on by default. This adds the "repository row" above the commit input box. By enabling this by default, user can see more context of the current repository, e.g. name, branch, ahead/behind status, etc.
2. There is a new scm.showActionButton setting, also on by default, to allow SCM extensions (e.g. Git) to add a big "action" button to the SCM view (per repository). Currently the API to support this new action button is proposed here
   • For the Git extension, we add a "Sync Changes" button as shown above, if there are unpushed commits, or a "Publish Changes" button if the branch isn't published.
   • The Git extension also adds a new git.showUnpublishedCommitsButton to control the behavior of the new action button
     • always — will always show the button if there are unpushed or unpublished changes
     • whenEmpty — will only show the button if there are unpushed or unpublished changes and the repository doesn't have any other changes (e.g. the view is empty)
     • never — will never show the button

[eamodio]

FYI, for this next release we are reverting the change to turn on scm.alwaysShowRepositories by default (we will revisit that in the next iteration. But we are leaving the scm.showActionButton on by default for this release.