Re: [PATCH v2 0/4] git-gui: Add ability to revert selected hunks and lines

On Fri, Aug 23, 2019 at 03:31:03AM +0530, Pratyush Yadav wrote:

We've had these features for years in git-cola.

Please copy our keyboard shortcuts. IMO we should not re-invent the user interactions.

http://git-cola.github.io/share/doc/git-cola/hotkeys.html

Ctrl-u is our revert-unstaged-edits hotkeys. "s" is for staging/unstaging (or Ctrl-s if the file list is focused).

The same hotkey is used for operating at the line level. If no lines are selected, the hunk surrounding the current cursor position is used.

Please make keyboard interaction a first-class design consideration.

I have a very strong opinion about the confirmation dialog, so I'll just mention that here since Hannes is on this thread.

In cola we do have a confirmation dialog, and I strongly believe this is the correct behavior because it's an operation that drops data that cannot be recovered.

In the other thread, it was mentioned that this dialog would be a nuisance. Perhaps that is true -- for the dialog that may have been implemented in this series (I haven't run it to verify).

Let's dive into that concern.

In git-cola we have a confirmation dialog and it is by no way a detriment to the workflow, and I use that feature all the time. Why? The reason is that we focused on the keyboard interaction.

The workflow is as follows:

	Ctrl-u to initiate the revert action
	The prompt appears immediately.
		- Hitting any of "enter", "y", or "spacebar" will
		  confirm the confirmation, and proceed.
		- Hitting any of "escape" or "n" will cancel the action.

So essentially the workflow for the power user becomes "ctrl-u, enter" and that is such a tiny overhead that it really is not a bother at all.

On the other hand, if I had to actually move my hand over to a mouse or trackpad and actually "click" on something then I would be super annoyed. That would be simply horrible with RSI in mind.

OTOH having to hit "enter" or "spacebar" (which is the largest key on your keyboard, and your thumbs have good hefty muscles) is totally acceptable in my book because it strikes the right balance between safety for a destructive operation and convenience.

Now, let's consider the alternative -- adding an option to disable the prompt. I don't like that.

Why? It's yet another option. It's yet another thing to document, yet another code path, and yet another pitfall for a user who might run git-gui in a different configuration (and becomes surprised when revert doesn't prompt and suddenly loses their work).

Do we really need an option, or do we need better usability instead? My opinion is that the latter is the real need.

That's my $.02 from having used this feature in practice since 2013.