Decide on and implement UX for checkout / commit workflow in SCM view

[mattseddon]

This question goes all the way back to #318 (comment).

Do we want to combine actions to make checkout / commit easier to users? What should the UI/UX be to simplify the process or moving between git commits / revisions?

[mattseddon]

Notes from chat @aguschin:

1. Commit flow looks good.
2. Reset workspace should be a single command, also can we run without the prompt? - could have two commands.
3. It would be good to have a shortcut to search through git revisions and select one then checkout both git and DVC to that revision.

[mattseddon]

From conversation with @shcheklein:

The new reset workspace command seems to be the nuclear option. Would it be possible to keep our command isolated from the rest of the git changes in the future? I.e can we only reset the files that relate to our DVC changes?

[mattseddon]

I now see 3 options for progressing with the commit workflow.

Each demo follows the same steps. They are:

1. start with (DVC tracked) modified resources in the workspace.
2. dvc commit
3. observe changes to UI
4. discard git changes
5. observe changes to UI

Current approach (Option 1):

Screen.Recording.2021-10-07.at.8.54.55.am.mov

Currently both modified and "stage modified" appear underneath our "Changes" resource group. Under this setup we cannot easily change the inline commands based on the status that the resource has. This means that the stage modified resources still have inline commands of commit and checkout. There is no point in having these commands inline as they do not actually do anything.

That led me to...

Split across different resource groups (Option 2 #880):

Screen.Recording.2021-10-07.at.8.52.39.am.mov

In this option we move the "stage modified" resources to a "Staged Changes" resource group (actual name tbd). By moving these resources to another resource group we can drop the inline commands (which as previously stated do not make sense).

Which led me to...

Remove stage modified status (Option 3 #881):

Screen.Recording.2021-10-07.at.8.49.44.am.mov

From working through options 1 and 2 I realised that there there could be a simpler way to show DVC changes and that is to drop the stage modified status. This then makes a clear split between when the user needs to perform actions in DVC and when they need to do something with git.

IMO option 3 is actually the best way to proceed. It stops us having to mix semantics within dvc status and should (hopefully) lead to simpler code in both DVC and in our extension.

Will discuss with @shcheklein and then loop in the DVC team once we have a clearer idea of what we think is the best path forwards.

[mattseddon]

Spoke with @shcheklein the preference is to go with option 2 for now. I will update #880 with the changes that we talked about this morning.