# git-ls-files in subdirectories ignore higher-up .gitignore 6 messages from 2006-01-24 to 2006-02-10. Participants: Pavel Roskin, Junio C Hamano, Sam Ravnborg. Thread: https://gitlist.dev/t/3139 ## Pavel Roskin, 2006-01-24 17:59 Subject: git-ls-files in subdirectories ignore higher-up .gitignore Message-ID: <1138125570.24415.11.camel@dv> URL: https://gitlist.dev/e/1138125570.24415.11.camel%40dv ``` Hello! git-ls-files appears to behave in a way that may be unexpected to the users. When run in a subdirectory, git-ls-files never reads .gitignore or whatever is specified by --exclude-per-directory in the parent directories. This can be demonstrated in git's own repository: $ touch t/test.o $ git-ls-files --others --exclude-per-directory=.gitignore $ cd t $ git-ls-files --others --exclude-per-directory=.gitignore test.o $ Before I attempt to fix it, I'd like to make sure it's a bug, not a feature. -- Regards, Pavel Roskin ``` ## Junio C Hamano, 2006-01-25 02:08 Subject: Re: git-ls-files in subdirectories ignore higher-up .gitignore Message-ID: <7vhd7t3vqf.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vhd7t3vqf.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <1138125570.24415.11.camel@dv> ``` Pavel Roskin writes: > This can be demonstrated in git's own repository: > > $ touch t/test.o > $ git-ls-files --others --exclude-per-directory=.gitignore > $ cd t > $ git-ls-files --others --exclude-per-directory=.gitignore > test.o > $ > > Before I attempt to fix it, I'd like to make sure it's a bug, not a > feature. I am not sure if that is a bug or a feature, but you are right. We do not bother to go uplevel and look for .gitignore in the current code. It would probably be a welcome addition if your fix made these two sequences work similarly modulo leading paths from the command output. I think it is natural to expect they are moral equivalents: (Sequence 1) $ touch t/test.o t/garbage $ git-ls-files -o --exclude-per-directory=.gitignore t/ (Sequence 2) $ touch t/test.o t/garbage $ cd t $ git-ls-files -o --exclude-per-directory=.gitignore ``` ## Sam Ravnborg, 2006-01-25 06:11 Subject: Re: git-ls-files in subdirectories ignore higher-up .gitignore Message-ID: <20060125061140.GA8408@mars.ravnborg.org> URL: https://gitlist.dev/e/20060125061140.GA8408%40mars.ravnborg.org In-Reply-To: <1138125570.24415.11.camel@dv> ``` On Tue, Jan 24, 2006 at 12:59:30PM -0500, Pavel Roskin wrote: > Hello! > > git-ls-files appears to behave in a way that may be unexpected to the > users. When run in a subdirectory, git-ls-files never reads .gitignore > or whatever is specified by --exclude-per-directory in the parent > directories. > > This can be demonstrated in git's own repository: > > $ touch t/test.o > $ git-ls-files --others --exclude-per-directory=.gitignore > $ cd t > $ git-ls-files --others --exclude-per-directory=.gitignore > test.o > $ > > Before I attempt to fix it, I'd like to make sure it's a bug, not a > feature. I for one consider it a bug. I expect exactly same output if I do git ls-files t/ or cd t; git ls-files Very usefull when I limit grep to some part of the kernel tree for example. Sam ``` ## Junio C Hamano, 2006-02-09 08:16 Subject: [PATCH] ls-files: honour per-directory ignore file from higher directories. Message-ID: <7vmzh1eykq.fsf_-_@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vmzh1eykq.fsf_-_%40assigned-by-dhcp.cox.net In-Reply-To: <20060125061140.GA8408@mars.ravnborg.org> ``` When git-ls-files -o --exclude-per-directory=.gitignore is run from a subdirectory, it did not read from .gitignore from its parent directory. Reading from them makes output from these two commands consistent: $ git ls-files -o --exclude-per-directory=.gitignore Documentation $ cd Documentation && git ls-files -o --exclude-per-directory=.gitignore Signed-off-by: Junio C Hamano --- * If there are positive feedbacks on this one, I consider it a safe enough candidate to be included in 1.2.0 release. ls-files.c | 22 +++++++++++++++++++++- 1 files changed, 21 insertions(+), 1 deletions(-) 701ca744e386c2429ca44072ea987bbb4bdac7ce diff --git a/ls-files.c b/ls-files.c index 6af3b09..7024cf1 100644 --- a/ls-files.c +++ b/ls-files.c @@ -474,8 +474,28 @@ static void show_files(void) const char *path = ".", *base = ""; int baselen = prefix_len; - if (baselen) + if (baselen) { path = base = prefix; + if (exclude_per_dir) { + char *p, *pp = xmalloc(baselen+1); + memcpy(pp, prefix, baselen+1); + p = pp; + while (1) { + char save = *p; + *p = 0; + push_exclude_per_directory(pp, p-pp); + *p++ = save; + if (!save) + break; + p = strchr(p, '/'); + if (p) + p++; + else + p = pp + baselen; + } + free(pp); + } + } read_directory(path, base, baselen); qsort(dir, nr_dir, sizeof(struct nond_on_fs *), cmp_name); if (show_others) -- 1.1.6.gbb042 ``` ## Pavel Roskin, 2006-02-10 03:38 Subject: Re: [PATCH] ls-files: honour per-directory ignore file from higher directories. Message-ID: <1139542730.23725.3.camel@dv> URL: https://gitlist.dev/e/1139542730.23725.3.camel%40dv In-Reply-To: <7vmzh1eykq.fsf_-_@assigned-by-dhcp.cox.net> ``` Hello, Junio! On Thu, 2006-02-09 at 00:16 -0800, Junio C Hamano wrote: > When git-ls-files -o --exclude-per-directory=.gitignore is run > from a subdirectory, it did not read from .gitignore from its > parent directory. Reading from them makes output from these two > commands consistent: You beat me at that. Thank you! With this patch, the simplified version of cg-clean passes the cogito testsuite. That's where the original bug was caught. > * If there are positive feedbacks on this one, I consider it > a safe enough candidate to be included in 1.2.0 release. Yes, it would be nice to see it released. -- Regards, Pavel Roskin ``` ## Junio C Hamano, 2006-02-10 04:44 Subject: Re: [PATCH] ls-files: honour per-directory ignore file from higher directories. Message-ID: <7vhd77zuts.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vhd77zuts.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <1139542730.23725.3.camel@dv> ``` Pavel Roskin writes: > With this patch, the simplified version of cg-clean passes the cogito > testsuite. That's where the original bug was caught. Thanks for testing it. ```