Re: Bug Report: .gitignore behavior is not matching in git clean and git status

From: Junio C Hamano <gitster@pobox.com>
Date: May 2, 2017, 00:26 UTC
Message-ID: <xmqqshkof6jd.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAJZjrdXVopdvDoDwnsmqvrLESKQq=-a2waDgu5HYYoP2WvSrPA@mail.gmail.com>

Samuel Lijin <sxlijin@gmail.com> writes:

Show 7 quoted lines

> After some more digging (and familiarizing myself with the
> behind-the-scenes logic) the issue is that dir.c has this implicit
> assumption that a directory which contains only untracked and ignored
> files should itself be considered untracked. While that works fine for
> use cases where we're asking if a directory should be added to the git
> database, that decidedly does not make sense when we're asking if a
> directory can be removed from the working tree.

Thanks for digging.

Show 5 quoted lines

> I'm not sure where to proceed from here. I see two ways forward: one,
> builtin/clean.c can collect ignored files when it calls
> dir.c:fill_directory(), and then clean -d can prune out directories
> that contain ignored files; two, path_treatment can learn about
> untracked directories which contain excluded (ignored) files.

My gut feeling is that the former approach would be of lesser impact. Directory A/ can be removed "clean" without "-x" when there is nothing tracked in there in the index and there is no ignored paths. Having zero untracked files there or one or more untracked file there do not matter---they are all subject to removal by "clean".