From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 27 Oct 2011 17:23:15 GMT
Subject: Re: [PATCH/WIP 02/11] notes-merge: use opendir/readdir instead of using read_directory()
Message-ID: <7vzkgmz6v0.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8C4iHffr4UYP9SvCU0OPC-LocUORwAQ492LqaV_tyvFQA@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds@gmail.com> 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 <path,len> are traversed.

I do not see any good reason for <path,len> to become a match pattern. Are
you trying to get it prepended to elements in pathspec[] and match the path
collected including the <path> part?

Why?

I could see that "open . and start from there, treating as if <path,len>
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 <path,len>? Maybe they should be the one that needs
fixing instead?