git clean -Xdf affects parent and sibling directories

git clean -Xdf affects parent and sibling directories

[Jan Berges]

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

Re: git clean -Xdf affects parent and sibling directories

[Junio C Hamano]

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.

Re: git clean -Xdf affects parent and sibling directories

[Jan Berges]

On 2/7/25 22:24, Junio C Hamano wrote:
> The command should take the usual pathspec, so "git clean ." should work as expected.

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