git clean not removing sub-directories (not recursive)

Question

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 not working recursively?

Kwarteng

Answer 1

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

Calliopsis

Couldn't agree more - git clean -df for the win, awesome -n flag for testing before breaking. :) – Counterclaim

Answer 2

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.

Serai

Might be nice if it did go up the tree, and everywhere in the tree given that git status does that but is possibly by design. – Clarinda

Answer 3

try this:

git clean -xdf

let me know if that worked.

Gavingavini

Answer 4

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.

Seidule

Answer 5

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.

Kachine

Answer 6

Use git clean -di. It will recurse, show the files, and ask what to do.

Example:

$ git clean  -di
Would remove the following items:
  src/main/java/org/jabref/logic/util/comparator/
  src/test/java/org/jabref/logic/util/comparator/
  src/test/resources/org/jabref/logic/quality/
  src/test/resources/org/jabref/logic/search/search/
*** Commands ***
    1: clean                2: filter by pattern    3: select by numbers
    4: ask each             5: quit                 6: help
What now> 1
Removing src/main/java/org/jabref/logic/util/comparator/
Removing src/test/java/org/jabref/logic/util/comparator/
Removing src/test/resources/org/jabref/logic/quality/
Removing src/test/resources/org/jabref/logic/search/search/

Daly