From: Johannes Schindelin Date: Thu, 28 Sep 2006 00:26:51 GMT Subject: Re: [PATCH] runstatus: do not recurse into subdirectories if not needed Message-ID: In-Reply-To: <7vac4k97if.fsf@assigned-by-dhcp.cox.net> Hi, On Wed, 27 Sep 2006, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This speeds up the case when you run git-status, having an untracked > > subdirectory containing huge amounts of files. > > > > It also clarifies the handling of hide_empty_directories; the old version > > worked, but was hard to understand. > > > > Signed-off-by: Johannes Schindelin > > --- > > dir.c | 24 +++++++++++++++--------- > > 1 files changed, 15 insertions(+), 9 deletions(-) > > > > diff --git a/dir.c b/dir.c > > index e2f472b..e69663c 100644 > > --- a/dir.c > > +++ b/dir.c > > @@ -274,6 +274,15 @@ static int dir_exists(const char *dirnam > > return !strncmp(active_cache[pos]->name, dirname, len); > > } > > > > +static int dir_is_empty(const char *dirname) > > +{ > > + DIR *fdir = opendir(dirname); > > + int result = (readdir(fdir) == NULL); > > + > > + closedir(fdir); > > + return result; > > +} > > + > > Does this really check if the directory is empty (I think you > would read "." and ".." out of it at least)? > > When the original code recurses into subdirectory, it seems to > behave identically for a truly empty directory and a directory > that has only ".git" (or excluded files in it under !show_ignored). Of course I missed that. Probably, because there is no test for that. But given my experience of a very, _very_ slow git-status when I do not _care_ about that particular directory (even if it does contain .git and excluded files), is it really sensible to have _no_ way to disable hide_empty_directories when show_other_directories is enabled? Or would it make sense to disable hide_empty_directories altogether? Now, I could enhance dir_is_empty() to recursively test if the dir is empty, and return 0 on first sight of a not-excluded dir entry, but is it really worth the hassle? Ciao, Dscho