Git 'Amend' can cause confusion

[westbury]

A number of our users are getting into trouble when they press 'Amend'. Often 'Amend' is pressed more than once because the user did not notice that it really did anything. At this point the user is stuck, the only thing they can do is to press 'Commit'. They then have a merged commit of a number of commits, but it is not obvious that this is what happened unless the user uses other tools to have a look. They then have to use the Git CLI or some other tool to restore.

It is hard to know what should be happening, but the current implementation is a definite UX issue.

This is a follow-on from #1746

[svenefftinge]

I agree that it can be confusing. If you know what it does it is however super useful.
So I'd like to find terminology and UX that will clearly guide the user and prohibits her from making mistakes. The underlying git command is something like git reset --soft HEAD~1.
How about calling it 'soft reset', with a lengthy hover information, explaining what it does?

[westbury]

Making it clear what 'Amend' does may help, though I like that the button is next to the commit so one knows exactly what one is amending. However I think this really needs the following:

1. A means of cancelling. This should be prominent, perhaps a second 'Cancel' or 'Abort' button alongside the 'Commit' button (if there is space for it). Should this cancel the entire 'amend', or just take back out the last commit added to the 'amend'? Alternatively could it help to have a general 'undo' action that always undoes the last action?

2. A change in the view to make it clear that we are amending a commit. If multiple commits have been merged then it should be clear that this is what the currently staged files are. I don't know how to best show this information.

[westbury]

I've had a discussion with our UX team and they are taking this on. It may take a few weeks to run some iterations through the sessions with the users.

One initial comment is that the flow is out of order. If flow is going from top to bottom then we start at the top with unstaged changes, then the staged changes (which would include a list of the commits being amended), then the commit message, commit button, and at the bottom the unamended commits, newest at the top (though we only show one). Most Git clients seem to go top to bottom, VSCode goes bottom to top.

[thegecko]

cc @sophewilliams

[westbury]

Changes that address this issue have been pushed here:
https://github.com/westbury/theia/tree/3851-amend

A few odd more things to do before this is ready for a PR.

[westbury]

This has been resolved by #4279 which included the work discussed here.