Jan Berges <jan.berges@xxxxxxxxxxxxx> writes: > Run git clean -Xdf in a subdirectory of a directory ignored by Git. > > What did you expect to happen? (Expected behavior) > All contents of this subdirectory are removed. From the man page: > "Cleans the working tree [...], starting from the current directory" > > What happened instead? (Actual behavior) > Ignored contents of parent and sibling directories are also removed. Interesting observation. Behind Git as a whole, there is a philosophy to track the entire working tree as a single unit, so touching a file at the top-level or in one subdirectory, going into a different subdirectory and running "git status" and "git diff" would show changes, in line with the spirit of tracking the whole tree as a single unit, made to that file outside your current directory. Of course, if you add changes to a file at the top-level or a subdirectory, chdir to a different subdirectory, touch some other files there, and say "git commit -a", these changes outside your current directory would also be recorded. The behaviour comes from the same principle. I think "git grep" is a notable oddball. Its UI is build around the guess that end users would expect a similarity with vanilla "grep" run with the "-r" option, so it only looks at the current directory or below. In hindsight, some may argue that "git clean" should also be an exception, but I doubt that would have been a good UI even back then, forcing end-users to remember which ones are always full-tree operation and which ones are current-directory-and-below. To limit the extent of potential damage, I'd always do a dry run with "git clean -n" first, giving other arguments I intend to give for the real run, and then swap "-n" with "-f". The command should take the usual pathspec, so "git clean ." should work as expected. HTH.
