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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux