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. Thanks, -- Sergey Organov
