git clean not removing sub-directories (not recursive)

I am facing problems with git clean. Consider the following scenario:

git status -su
?? file_1
?? xyz/file_2

git clean -f
Not removing xyz/file_2
Removing file_1

I don't want to remove the xyz folder, but I want to remove the file_2 inside it.

Why is git clean is开发者_如何学Go not working recursively?

If you have it in ignore, use git clean -xf. You can do git clean -xdf but that will also remove untracked directories. Use -n for a dry-run.

http://gitready.com/beginner/2009/01/16/cleaning-up-untracked-files.html

Also, git clean doesn't work up the directory tree. Consider you have

> git status
Untracked files:
  ../file1.orig
  ../../file2.orig

git clean -df would do nothing in this state. You have to 'cd' into the project root and run 'git clean -df' there again.

try this:

git clean -xdf

let me know if that worked.

Perhaps you have the xyz directory in your .gitignore file somewhere? You can override this behaviour using the -x switch to clean. Also, if the xyz directory is not tracked (has nothing inside it that is tracked), it will not be removed unless you pass the -d option.

Note that, on Widows, even a git clean -xdf might fail, silently skipping a path when it cannot lstat() it; now (Git 2.23, Q3 2019), it gives a warning.

See commit b09364c (18 Jul 2019) by Johannes Schindelin (dscho).
Helped-by: René Scharfe (rscharfe), SZEDER Gábor (szeder), and Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit f3d508f, 25 Jul 2019)}

clean: show an error message when the path is too long

When lstat() failed, git clean would abort without an error message, leaving the user quite puzzled.

In particular on Windows, where the default maximum path length is quite small (yet there are ways to circumvent that limit in many cases), it is very important that users be given an indication why their command failed because of too long paths when it did.

This test case makes sure that a warning is issued that would have helped the user who reported git-for-windows/git issue 521

Note that we temporarily set core.longpaths = false in the regression test; this ensures forward-compatibility with the core.longpaths feature that has not yet been upstreamed from Git for Windows.