On Fri, Aug 23, 2019 at 03:31:03AM +0530, Pratyush Yadav wrote: > Hi, > > This series adds the ability to revert selected lines and hunks in > git-gui. Partially based on the patch by Bert Wesarg [0]. > > The commits can be found in the topic branch 'py/revert-hunks-lines' > at https://github.com/prati0100/git-gui/tree/py/revert-hunks-lines > > Once reviewed, pull the commits from > 415ce3f8582769d1d454b3796dc6c9c847cefa87 till > 0a1f4ea92b97e673fda40918dae68deead43bb27, or just munge the patches and > apply them locally, whichever you prefer. > > Changes in v2: > - Add an option to disable the revert confirmation prompt as suggested > by Johannes Sixt. > - Base the patches on Pat's git-gui tree instead of git.git. 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. -- David
