Re: what should "git clean -n -f [-d] [-x] <pattern>" do?

[Sergey Organov <sorganov@gmail.com>]

Junio C Hamano <gitster@pobox.com> writes:

> I think the current code makes "-n" take precedence, and ignores
> "-f".

To me it rather looks more like "-n" implies "-f", but then there is
"second -f" rule that makes things even more interesting:

  "Git will refuse to modify untracked nested git repositories
   (directories with a .git subdirectory) unless a second -f is given."

How do I figure what files will be deleted on

  git clean -f -f

when "-n" behaves as you (or me) described? I.e., what

  git clean -f -f -n

and

  git clean -f -n

will output?

>
> Shouldn't it either
>
>  (1) error out with "-n and -f cannot be used together", or
>  (2) let "-n" and "-f" follow the usual "last one wins" rule?
>
> The latter may be logically cleaner but it is a change that breaks
> backward compatibility big time in a more dangerous direction, so it
> may not be desirable in practice, with too big a downside for a too
> little gain.

I agree (2) is too dangerous and surprising, and (1) is limiting: I
believe the user should be able to see what will be done on

   git clean -f -f

by simply adding "-n" to the command-line.

So I figure I'd rather prefer yet another option:

(3) -n  dry run: show what will be done once "-n" is removed.

This way, e.g.,

  git clean

and

  git clean -n

will produce exactly the same output with default configuration:

  fatal: clean.requireForce defaults to true and neither -i, nor -f given; refusing to clean

and one will need to say, e.g.:

  git clean -n -f

to get the list of files to be deleted with "git clean -f".

With (3) "-n" becomes orthogonal to "-f", resulting in predictable and
useful behavior.

BR,
-- Sergey Organov