Hi Matthieu, On Mon, May 6, 2013 at 3:58 AM, Matthieu Moy <matthieu....@grenoble-inp.fr> wrote: > Eric Sunshine <sunsh...@sunshineco.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html