Re: [PATCH v4 2/5] dir_iterator: iterate over dir after its contents

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Mar 30, 2017, 06:39 UTC
Message-ID: <1751d788-d1f1-1c97-b33b-f53dab78ef86@alum.mit.edu>
In-Reply-To: <xmqqinmr70uc.fsf@gitster.mtv.corp.google.com>

On 03/30/2017 08:08 AM, Junio C Hamano wrote:

Show 9 quoted lines

> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> I think IN_ORDER really only applies to *binary* trees, not arbitrary
>> trees like a filesystem.
> 
> How true.  Even if we were giving a sorted output (and dir-iterator
> doesn't and there is no need for it to), dir/ should come before any
> of its contents, so for that application we can use pre-order, and
> there is no sensible and useful definition of in-order.

Your email got me thinking, though, that there is one generalization of the concept of PRE_ORDER vs. POST_ORDER that would be both easy to implement and potentially useful. Namely, flags could include the following orthogonal options (instead of `DIR_ITERATOR_POST_ORDER)`:

* DIR_ITERATOR_DIRS_BEFORE -- when this is set, directories
  are included in the iteration *before* their contents.

* DIR_ITERATOR_DIRS_AFTER -- when this is set, directories
  are included in the iteration *after* their contents.

Enabling one or the other of these options would select pre-order or post-order iteration.

Enabling neither of them would mean that directory entries themselves are not included in the iteration at all, even though recursion would happen *into* subdirectories. This option would surely be useful to some caller somewhere (though it's easy for the caller to get the same effect itself via

	if (S_ISDIR(iter->base.st.st_mode))
		continue;

).

It's even conceivable that enabling *both* options at the same time would be useful, if the caller want to know when the processing of a directory is begun and also when it is finished (e.g., because it needs to load or unload a `.gitignore` file for that directory). If we wanted to make it easier for the caller figure out whether it is seeing an "entering directory" event vs. a "leaving directory" event, we could expose something like the `dir_state` member in the iterator.

While we're blue-skying, a

* DIR_ITERATOR_RECURSE -- recurse into subdirectories

would make the set of possible options complete. If this option is not set, then the iteration would be over the entries in a single directory without traversing its subdirectories.

I don't think any of this needs to be implemented now, but maybe keep it in mind if/when `dir_iterator` gets more users.

Michael