Hi Matthieu,
On Mon, May 6, 2013 at 3:58 AM, Matthieu Moy
<Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
> Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
>
>> The pattern [y] will match file named 'y'. It probably is unusual for
>> files named 'y', 'n', etc. to exist in the top-level directory, but
>> the gitignore patterns already provide an escape hatch for these
>> unusual cases.
>
> But how does the user know that?
Documentation. Junio also mentioned having a '?' in each prompt
explaining the options at that point.
> I'd rather stay away from dwim that works in 99% of cases but do
> something dangerous in the 1% remaining, and complex un-guessable escape
> scheme to solve these few cases. The two stages (yes/no/edit, and then
> escape patterns) is clear, and does not require so many additional
> keystrokes.
The scheme doesn't have to be unsafe. git-clean *knows* which files
are up for deletion. If one of those filenames conflicts with one of
the prompt options, --interactive mode can warn about the ambiguity at
the point the user types that particular ambiguous response, and ask
for clarification ("did you mean 'yes, delete everything' or 'exclude
filename y'?"). You get DWIM for 99.9% of the cases, and an extra
prompt for the other 0.1%. Nothing unsafe. Is such an implementation
more complicated or ugly than the separate 'edit' mode? Is the user
experience better or worse (more or less convenient)? Is it easier or
harder to document and explain?
Another observation which came to mind after my original email:
Would it make sense for --interactive mode to launch an editor with
the list of files scheduled for deletion and allow the user to remove
lines he does not want deleted (similar to "git-rebase
--interactive"). Depending upon case, this could be more or less
convenient than the proposed gitignore-patterned 'edit' mode. It could
be yet another option in the yes/no/prompt/edit menu or it could be
the default and only behavior of "git-clean --interactive" (again
similar to "git-rebase --interactive).
I'm not advocating any particular user interface. The observations and
questions about convenience and user experience both here and in my
original email were made with the hope of promoting discussion before
the interface gets locked in. How clunky or fluid should it be? How
verbose or terse?
-- ES
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html