Is there ever a reason to use git clean without -f?

Question

As I understand it, the purpose of git clean is to delete untracked files. But it won't (by default) run without the -f flag. I can understand the -f flag for commands that do something besides delete stuff, because I might run them to do one thing, without realizing that it will also delete files as a side-effect. But if I run git clean, I know I'll be deleting files.

Is this just a safety mechanism, like an "Are you sure" popup? Or is there actually something else git clean can do without the -f flag?

Answer 1

But it won't (by default) run without the -f flag.

Actually, git clean will refuse to perform anything unless you specify -f, -i or -n. You are required to specify at least one of them.

-nis for "dry run" (showing what would be done without actually deleting files). The two others one act just like the rm command. "force" (silently deleting everything that matches) or "interactive" (explicitly ask the user for each matching file).

Is this just a safety mechanism, like an "Are you sure" popup?

To my eyes, that's indeed an efficient way to introduce the thing.

git clean is actually very dangerous, as it looks like a common command but actually will delete everything that is not already stored, which would make of it one of the rare commands that may actually loose data with no hope of recovery. Knowing that most of beginners already rush into "git checkout -f" and "git reset --hard", we easily understand that such a security step is not useless.

In particular, "git clean -f" would delete every new file that has not been added yet ! This could be for example a brand new module you've been writing all day for the project you're working on.

Also, when git is used to work on a software development project (that is, the most frequent use case) one could assume that "git clean" works the same way that "make clean", which would be a big mistake. The latter one is made to clean up its own crap and knows exactly what to look for. Git would do the opposite.

The normal way of working for a SCM is to never touch what has not explicitly been tracked once. git clean is essentially made to either restore the initial state of an existing repository to avoid having to drop it and re-clone it again, or to actually clean up everything that's useless once we've done with a big task, before starting sharing the thing.

If I was a system administrator and if this was possible, I would configure git clean's default behavour as -i, instead of simply prompting user with available options, just like rm is on most distributions. This shows a message telling exactly what is currently being done and give a chance to people that don't know what they do to stop before it's too late. Simply being prompted for '-f', '-i' or '-n' is a risk for the user to opt for '-f' by default.

Answer 2

Here is the commit where the -f option was included:

https://github.com/git/git/commit/2122591b3b5c6d93d3052a3151afcfa3146ede84#diff-3099dbcff3411d798a74588a2638748e

It says:

Add clean.requireForce option, and add -f option to git-clean to over…

…ride it

Add a new configuration option clean.requireForce. If set, git-clean will refuse to run, unless forced with the new -f option, or not acting due to -n.

Later fixed: https://github.com/git/git/commit/89c38500192e00988966246420902dc946e4f4ef#diff-3099dbcff3411d798a74588a2638748e

git-clean: fix the description of the default behavior

Currently, when called without -n and -f, git clean issues

fatal: clean.requireForce not set and -n or -f not given; refusing to clean

which leaves the user wondering why force is required when requireForce is not set. Looking up in git-clean(1) does not help because its description is wrong.

Change it so that git clean issues

fatal: clean.requireForce defaults to true and -n or -f not given; refusing to clean

in this situation (and "...set to true..." when it is set) which makes it clearer that an unset config means true here, and adjust the documentation.