Sergey Organov <sorganov@xxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Sergey Organov <sorganov@xxxxxxxxx> writes: >> >>> Now we are going to introduce "dry run" option "-n". Most simple and >>> obvious way to do it is to set internal flag "dry_run" and then at every >>> invocation of "remove(file_name)" put an if(dry_run) that will just >>> print(file_name) instead or removing it. Let's suppose we did just that. >>> We get this behavior: >>> >>> $ git clean -n >>> fatal: clean.requireForce defaults to true and neither -i nor -f given; refusing to clean >>> $ git clean -f -n >>> would remove "a" >>> would remove "b" >>> $ git clean -f -f -n >>> would remove "a" >>> would remove "b" >>> would remove "sub/a" >>> $ >>> >>> I see this as logical, clean, and straightforward behavior, meeting user >>> expectations for "dry run" option, so I suggest to do just that. >> >> I think we are saying the same thing. If the original semantics >> were "you must force with -f to do anything useful", instead of "you >> must choose either forcing with -f or not doing with -n", then it >> would have led to the above behaviour. >> >> The thing is, it is way too late to change it that way without >> breaking too many folks, and that is the problem. > > If we agree on the behavior above for sane "dry run", yet you worry > about backward compatibility so much to deny changing the behavior of > "-n", then a way to go could be to introduce, say, "-d" for sane "dry > run", and obsolete "-n" while keeping it alone. Except exactly "-d" is already taken, but you get the idea. -- Sergey Organov
