# [BUG] git clean -X behaviour when .gitignore has sub-directory entries 4 messages from 2010-09-27 to 2010-10-03. Participants: Jean-Philippe Gariépy, Jonathan Nieder. Thread: https://gitlist.dev/t/25259 ## Jean-Philippe Gariépy, 2010-09-27 14:35 Subject: [BUG] git clean -X behaviour when .gitignore has sub-directory entries Message-ID: <4CA0AB9A.4050002@nuecho.com> URL: https://gitlist.dev/e/4CA0AB9A.4050002%40nuecho.com ``` (this is a repost w/ a bit more context) Hi, Context: "git clean -X" is really helpful in my projects to mimick a "make clean" (or more precisely a "make distclean") but I believe there is a small problem with the -X option of git clean. I've validated this with other people and they agree it's a bug. Problem: When using sub-directory entries in .gitignore, while the entry is ignored as expected, "git clean -X" doesn't clean the ignored sub-directory. $ git init test Initialized empty Git repository in /home/jpgariep/git/test/.git/ $ cd test/ $ mkdir -p a/b/c $ touch a/b/c/test $ echo '/a/b/' > .gitignore $ git add .gitignore $ git commit -m "Added .gitignore." [master (root-commit) 94e2825] Added .gitignore. 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 .gitignore $ git status # On branch master nothing to commit (working directory clean) $ git clean -X -d -f $ ls a b Why is b still there? Git version: git version 1.7.2.3 (but this has been around since 1.6.something) Tested also with 1.7.3.2.g9027fa (today's HEAD of master branch) Thanks. -- Jean-Philippe ``` ## Jonathan Nieder, 2010-09-27 20:36 Subject: Re: [BUG] git clean -X behaviour when .gitignore has sub-directory entries Message-ID: <20100927203652.GB11957@burratino> URL: https://gitlist.dev/e/20100927203652.GB11957%40burratino In-Reply-To: <4CA0AB9A.4050002@nuecho.com> ``` Hi, Jean-Philippe Gariépy wrote: > When using sub-directory entries in .gitignore, while the entry is > ignored as expected, "git clean -X" doesn't clean the ignored > sub-directory. Thanks for reporting. $ cat test.sh rm -fr test && git init test && ( cd test && mkdir -p a/b/c && >a/b/c/f && echo '/a/b/' >.gitignore && git status -s && git clean -X -d -n && git ls-files -o -i --exclude-standard && git ls-files -o --directory -i --exclude-standard && git clean -X -d -f && echo ... drumroll ... && ! test -e a/b/c/f ) $ sh test.sh || echo fail Initialized empty Git repository in /tmp/test/.git/ ?? .gitignore ... drumroll ... fail Variations: 1) echo '/a/' >.gitignore 2) echo '/a/b/c/f' >.gitignore 3) >a/b/f (1) does not fail; (2) and (3) still do. Okay, so why does this happen? Tracing: -- 8< -- diff --git a/dir.c b/dir.c index 133f472..5707ad0 100644 --- a/dir.c +++ b/dir.c @@ -693,6 +693,9 @@ static enum path_treatment treat_one_path(struct dir_struct *dir, int dtype, struct dirent *de) { int exclude = excluded(dir, path, &dtype); + + trace_printf("treat_one_path: path=%s exclude=%d\n", path, exclude); + if (exclude && (dir->flags & DIR_COLLECT_IGNORED) && exclude_matches_pathspec(path, *len, simplify)) dir_add_ignored(dir, path, *len); -- >8 -- $ GIT_TRACE=true PATH=/home/jrn/src/git/bin-wrappers:$PATH sh test.sh trace: built-in: git 'init' 'test' Initialized empty Git repository in /tmp/test/.git/ trace: built-in: git 'status' '-s' treat_one_path: path=.gitignore exclude=0 treat_one_path: path=a exclude=0 treat_one_path: path=a/b exclude=1 ?? .gitignore trace: built-in: git 'clean' '-X' '-d' '-n' treat_one_path: path=.gitignore exclude=0 treat_one_path: path=a exclude=0 trace: built-in: git 'ls-files' '-o' '-i' '--exclude-standard' treat_one_path: path=.gitignore exclude=0 treat_one_path: path=a exclude=0 treat_one_path: path=a/b exclude=1 treat_one_path: path=a/b/c exclude=0 treat_one_path: path=a/b/c/f exclude=0 trace: built-in: git 'ls-files' '-o' '--directory' '-i' '--exclude-standard' treat_one_path: path=.gitignore exclude=0 treat_one_path: path=a exclude=0 trace: built-in: git 'clean' '-X' '-d' '-f' treat_one_path: path=.gitignore exclude=0 treat_one_path: path=a exclude=0 ... drumroll ... $ 1) a/b/f is not actually considered excluded; only its containing directory is. 2) git clean does not even examine a/b to consider whether to remove it: since a/ does not contain any tracked files, it stopped there. The following would cause "git clean -ndx" to print more than it should, but hopefully it illustrates the idea. diff --git a/builtin/clean.c b/builtin/clean.c index b508d2c..91624c2 100644 --- a/builtin/clean.c +++ b/builtin/clean.c @@ -84,8 +84,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix) if (force > 1) rm_flags = 0; - dir.flags |= DIR_SHOW_OTHER_DIRECTORIES; - if (read_cache() < 0) die("index file corrupt"); -- ``` ## Jean-Philippe Gariépy, 2010-10-03 18:55 Subject: Re: [BUG] git clean -X behaviour when .gitignore has sub-directory entries Message-ID: <4CA8D1B4.1020801@nuecho.com> URL: https://gitlist.dev/e/4CA8D1B4.1020801%40nuecho.com In-Reply-To: <20100927203652.GB11957@burratino> ``` On 09/27/2010 04:36 PM, Jonathan Nieder wrote: > ... > 1) a/b/f is not actually considered excluded; only its containing > directory is. > > 2) git clean does not even examine a/b to consider whether to remove > it: since a/ does not contain any tracked files, it stopped there. Ok, thanks for your analysis. Do you consider it a bug? -- Jean-Philippe ``` ## Jonathan Nieder, 2010-10-03 19:12 Subject: Re: [BUG] git clean -X behaviour when .gitignore has sub-directory entries Message-ID: <20101003191209.GA22743@burratino> URL: https://gitlist.dev/e/20101003191209.GA22743%40burratino In-Reply-To: <4CA8D1B4.1020801@nuecho.com> ``` Jean-Philippe Gariépy wrote: > On 09/27/2010 04:36 PM, Jonathan Nieder wrote: >>... >> 1) a/b/f is not actually considered excluded; only its containing >> directory is. >> >> 2) git clean does not even examine a/b to consider whether to remove >> it: since a/ does not contain any tracked files, it stopped there. > > Ok, thanks for your analysis. Do you consider it a bug? Yes. ```