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.