Re: clean bug on ignored subdirectories with no tracked files?

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 19, 2011, 19:23 UTC
Message-ID: <7vy5vbj4rb.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAG+J_Dxw00e_cr7i3R9DAbTrqZvJHYk2yeUa=xGKh+Zqqmp-SA@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> writes:

Show 12 quoted lines

> git init test_repo &&
> cd test_repo &&
> mkdir -p foo/bar &&
> echo baz > foo/bar/baz &&
> echo /foo/bar > .gitignore &&
> git add .gitignore &&
> git clean -n -d
>
> Initialized empty Git repository in .../test_repo/.git/
> Would remove foo/
>
> Seems surprising.

You said "everythingthing in foo/bar is uninteresting and can be cleaned", you have one untracked file in "foo/bar" hierarchy, and you have nothing else in "foo/" hierarchy.

Removing the uninteresting cruft as your .gitignore instructs Git makes the entire "foo/" hierarchy devoid of any contents. I would *expect* Git to clean "foo" in this case.

I've seen some "surprising" behaviour in "git clean" (which I do not use myself, I do not consider part of "my code", and I am not surprised if it has many bugs), but I fail to see what is surprising in your transcript.

It would be a different issue if you had ">foo/other" before your "clean". Then "foo/" has "foo/clean" that is not declared to be uninteresting.