Good assessment/understanding of the issue. git clean -n does not report anything as being targeted for removal, and git clean -f matches that behavior. I agree with it probably being related specifically to the -d flag. As another experiment I modified .gitignore to ignore /A/B/C instead of /A/B/ and the same result occurs (-n reports nothing, -dn reports removing A/) Lastly, I changed .gitignore to just be /A/, and in doing so, clean -dn stops reporting that it will remove A/. I’m not exactly sure if this last one is surprising or not. Also, and sorry for the noise, but I did a reply-all here, but will a reply automatically include the rest of the list? Or was reply-all the right move? On Sun, Apr 30, 2017 at 9:41 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Chris Johnson <chrisjohnson0@xxxxxxxxx> writes: > >> I am a mailing list noob so I’m sorry if this is the wrong format or >> the wrong please. >> >> Here’s the setup for the bug (I will call it a bug but I half expect >> somebody to tell me I’m an idiot): >> >> git init >> echo "/A/B/" > .gitignore > > You tell Git that anything in A/B/ are uninteresting. > >> git add .gitignore && git commit -m 'Add ignore' >> mkdir -p A/B >> touch A/B/C > > And create an uninteresting cruft. > >> git status > > And Git does not bug you about it. > >> git clean -dn > > This incorrectly reports "Would remove A/" and if you gave 'f' > instead of 'n', it does remove A/, A/B, and A/B/C. > > Despite that "git clean --help" says 'only files unknown to Git are > removed' (with an undefined term 'unknown to Git'). What it wants > the term mean can be guessed by seeing 'if the -x option is > specified, ignored files are also removed'---so 'unknown to Git' > does not include what you told .gitignore that they are > uninteresting. IOW, Git knows they are not interesting. > > It looks like a bug in "git clean -d" to me. Do you see the same > issue if you use "git clean" without "-d"? IOW, does it offer to > remove A/B/C?