Re: [PATCH v5 0/3] interactive git clean

From: Eric Sunshine <sunshine@sunshineco.com>
Date: May 3, 2013, 10:37 UTC
Message-ID: <CAPig+cQALgr_VXwG5jBiFVTM627se8zQz7vsmF=A9OLcp_GT9A@mail.gmail.com>
In-Reply-To: <cover.1367551846.git.worldhello.net@gmail.com>

Usability observations below...

On Thu, May 2, 2013 at 11:49 PM, Jiang Xin <worldhello.net@gmail.com> wrote:

Show 11 quoted lines

> The interactive git clean combines `git clean -n` and `git clean -f`
> together to do safe cleaning, and has more features.
>
> First it displays what would be removed in columns (so that you can
> see them all in one screen). The user must confirm before actually
> cleaning.
>
>     WARNING: The following items will be removed permanently. Press "y"
>     WARNING: to start cleaning, and press "n" to abort the cleaning.
>     WARNING: You can also enter the "edit" mode, and select items
>     WARNING: to be excluded from the cleaning.

The user intended for files to be removed when invoking git-clean, therefore WARNING that git-clean will do what was requested explicitly seems overkill. Along the same lines, the user asked explicitly for an interactive session (via --interactive), hence the above paragraph is effectively redundant since it does little more than tell the user (in a lengthy fashion) what he already knows (that the session is interactive). The short prompt printed after the listed files says the same thing (more succinctly), thus this warning paragraph is essentially superfluous.

>       What would be removed...    What would be removed...
>       What would be removed...    What would be removed...
>
>     Remove (yes/no/Edit) ?

For convenience, implementations traditionally allow single letter responses (y/n/e), but this one does not. Should it?

Show 5 quoted lines

> In this confirmation dialog, the user has three choices:
>
>  * Yes: Start to do cleaning.
>  * No:  Nothing will be deleted.
>  * Edit (default for the first time): Enter the edit mode.

What about the user who desires more traditional "rm -i" behavior in which he is prompted for each file? Should that be supported with a "Prompt [each]" option in the above menu?

Show 5 quoted lines

> When the user chooses the edit mode, it would look like this:
>
>     NOTE: Will remove the following items. You can input space-seperated
>     NOTE: patterns (just like .gitignore) to exclude items from deletion,
>     NOTE: or press ENTER to continue.

As earlier, this (lengthy) paragraph says little more than what could be said in a more succinct prompt printed after the file list, thus is probably superfluous.

>       What would be removed...    What would be removed...
>       What would be removed...    What would be removed...
>
>     Input ignore patterns>

The list of files to be removed was already shown directly above. Dumping the entire list to the user's screen a second time upon entering edit mode seems unnecessary. If you drop the WARNING and NOTE paragraphs as suggested, then the session becomes much less verbose, thus there is little reason to re-display the file list upon entering edit mode. For instance:

  % git clean -i
  file1 file2 file3
  file4 file5 file6
  Remove (yes/no/edit)? e
  Exclude (space-separated gitignore patterns): file[4-6]
  file1 file2 file3
  Exclude (space-separated gitignore patterns): [enter]
  Remove (yes/no/edit)?

Show 17 quoted lines

> The user can input space-separated patterns (the same syntax as gitignore),
> and each clean candidate that matches with one of the patterns will be
> excluded from cleaning.
>
> When the user feels it's OK, presses ENTER and back to the confirmation dialog.
>
>     WARNING: The following items will be removed permanently. Press "y"
>     WARNING: to start cleaning, and press "n" to abort the cleaning.
>     WARNING: You can also enter the "edit" mode, and select items
>     WARNING: to be excluded from the cleaning.
>
>       What would be removed...
>
>     Remove (Yes/no/edit) ?
>
> This time the default choice of the confirmation dialog is "YES".
> So when user press ENTER, start cleaning.

Is there precedent for this sort of self-mutating default action in other utilities? Wouldn't this lead to high "surprise factor" for users and potential for lost files? For instance:

  % git clean -i
  file1 file2 file3
  file4 file5 file6
  Remove (yes/no/Edit)? [enter]
    {user presses ENTER for edit mode}
  Exclude (space-separated gitignore patterns): file[3-6]
    {user mistakenly types "3" rather than "4"}
  file1 file2
  Exclude (space-separated gitignore patterns): [enter]
  Remove (Yes/no/edit)? [enter]
    {user notices mistake and presses ENTER expecting edit mode}
  Removing file3
  Removing file4
  Removing file5
  Removing file6

Oh no! The user didn't notice the subtle change of default from "yes/no/Edit" to "Yes/no/edit", thus he pressed ENTER thinking it would take him to edit mode as it did initially, but instead git-clean proceeded with the removals and file3 is lost.

Other considerations:

Is it necessary to force the user to escape from edit mode by pressing ENTER (i.e. empty input)? Wouldn't you achieve the same level of functionality by exiting back to the (yes/no/edit) prompt automatically after the user enters his gitignore pattern(s)? For instance:

  % git clean -i
  file1 file2 file3
  file4 file5 file6
  Remove (yes/no/edit)? e
  Exclude (space-separated gitignore patterns): file[4-6]
  file1 file2 file3
  Remove (yes/no/edit)?

More generally, is this sort of modal edit mode desirable and convenient? Can the edit operation be combined with the top-level prompt? For example:

  % git clean -i
  file1 file2 file3
  file4 file5 file6
  Remove ([y]es, [n]o, [p]rompt, exclusion-list)? file[4-6]
  file1 file2 file3
  Remove ([y]es, [n]o, [p]rompt, exclusion-list)? p
  file1 (y/n/q/!)? y
  file2 (y/n/q/!)? n
  file3 (y/n/q/!)? y

-- ES