Re: git clean -Xdf affects parent and sibling directories

[Junio C Hamano <gitster@pobox.com>]

Jan Berges <jan.berges@uni-bremen.de> 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.