From: Nguyen Thai Ngoc Duy Date: Fri, 28 Oct 2011 20:47:44 GMT Subject: Re: [PATCH/WIP 02/11] notes-merge: use opendir/readdir instead of using read_directory() Message-ID: In-Reply-To: <7vzkgmz6v0.fsf@alter.siamese.dyndns.org> On Fri, Oct 28, 2011 at 4:23 AM, Junio C Hamano wrote: > Nguyen Thai Ngoc Duy writes: > >>> When read_directory("where/ever") is called, what kind of paths does it >>> collect? Do the paths the function collects share "where/ever" as their >>> common prefix? I thought it collects the paths relative to whatever >>> top-level directory given to the function, so that "where/ever" could be >>> anything. >> >> Correct. But read_directory() takes pathspec now so naturally it does >> not treat "where/ever" a common prefix anymore.  So it has to open(".") >> and starts from there. > > That is a puzzling statement. The read_directory() function takes: > >  - dir: use this struct to pass traversal status and collected paths; > >  - path, len: this is the directory (not a pathspec) we start traversal >   from; and > >  - pathspec: these are the patterns that specify which parts of the >   directory hierarchy under are traversed. > > I do not see any good reason for to become a match pattern. Are > you trying to get it prepended to elements in pathspec[] and match the path > collected including the part? > > Why? > > I could see that "open . and start from there, treating as if > is also pathspec" could be made to work, but I do not see why that is > desirable. > > In other words, are there existing callers that abuse read_directory() > to feed a pattern in ? Maybe they should be the one that needs > fixing instead? fill_directory() tries to calculate a common prefix (i.e. to read_directory()) from pathspec and that may or may not work when pathspec magic comes into play. But yes, I could just make fill_directory() pass <"",0> to read_directory() and keep in read_directory() for notes-merge and future users. -- Duy