Junio C Hamano <gitster@xxxxxxxxx> 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
