git clean -Xdf affects parent and sibling directories

Dear Git Developers,

This is probably not a bug, but a potentially dangerous behavior.

What did you do before the bug happened? (Steps to reproduce your issue) 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.

Anything else you want to add: The behavior can be reproduced using the following lines.

mkdir git_clean_test/ cd git_clean_test/

git init -q

mkdir -p dir1/sub1/ mkdir -p dir1/sub2/ mkdir -p dir2/sub1/ mkdir -p dir2/sub2/

touch dir1/sub1/file touch dir1/sub2/file touch dir2/sub1/file touch dir2/sub2/file

echo -e "file\ndir1" > .gitignore

for dir in dir1/sub1/ dir2/sub1/
do
     cd $dir
     pwd
     git clean -Xdn
     cd ~-
done

Output of the above lines:

/home/jan/git_clean_test/dir1/sub1 Would refuse to remove current working directory Would remove ../sub1/file Would remove ../sub2 /home/jan/git_clean_test/dir2/sub1 Would refuse to remove current working directory Would remove ./file

Thanks and kind regards,

Jan

[System Info]
git version:
git version 2.48.1.575.g74a3c43834
cpu: x86_64
built from commit: 74a3c43834882219aa12aa1815d441a1762ba558
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
libcurl: 7.88.1
OpenSSL: OpenSSL 3.0.15 3 Sep 2024
uname: Linux 6.1.0-30-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 
(2025-01-12) x86_64
compiler info: gnuc: 12.2
libc info: glibc: 2.36
$SHELL (typically, interactive shell): /bin/bash

Jan Berges <jan.berges@uni-bremen.de> writes:

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.

On 2/7/25 22:24, Junio C Hamano wrote:

Thank you for the explanations! I tried again with "git clean -Xf -- ." and this command still removes parent and sibling content. This seems to be at odds with the manual: "If any optional <pathspec>... arguments are given, only those paths that match the pathspec are affected."

As far as I can see, if <pathspec> is untracked and ignored, the command goes to the topmost ignored directory of the tree and cleans from there.

In the worst case, GIT_WORK_TREE=$HOME, GIT_DIR tracks dotfiles, and all other directories such as ~/Documents/ are ignored. Running the command in ~/Documents/path/to/another/repository/ would remove everything under ~/Documents/. (This is not exactly what I did; I did not lose any files. In any case, thanks for the advice to always do a dry run first!)

Jan