On 03/25/2017 07:12 PM, Daniel Ferreira wrote:
> Create an option for the dir_iterator API to iterate over a directory
> path only after having iterated through its contents. This feature was
> predicted, although not implemented by 0fe5043 ("dir_iterator: new API
> for iterating over a directory tree", 2016-06-18).
>
> This is useful for recursively removing a directory and calling rmdir()
> on a directory only after all of its contents have been wiped.
>
> An "options" member has been added to the dir_iterator struct. It
> contains the "iterate_dirs_after_files" flag, that enables the feature
> when set to 1. Default behavior continues to be iterating over directory
> paths before its contents.
>
> Two inline functions have been added to dir_iterator's code to avoid
> code repetition inside dir_iterator_advance() and make code more clear.
>
> No particular functions or wrappers for setting the options struct's
> fields have been added to avoid either breaking the current dir_iterator
> API or over-engineering an extremely simple option architecture.
>
> Signed-off-by: Daniel Ferreira <bnm...@gmail.com>
> ---
> dir-iterator.c | 100
> ++++++++++++++++++++++++++++++++++++++++++++-------------
> dir-iterator.h | 7 ++++
> 2 files changed, 84 insertions(+), 23 deletions(-)
>
> [...]
> diff --git a/dir-iterator.h b/dir-iterator.h
> index 27739e6..4304913 100644
> --- a/dir-iterator.h
> +++ b/dir-iterator.h
> @@ -38,7 +38,14 @@
> * dir_iterator_advance() again.
> */
>
> +struct dir_iterator_options {
> + unsigned iterate_dirs_after_files : 1;
> +};
> +
> struct dir_iterator {
> + /* Options for dir_iterator */
> + struct dir_iterator_options options;
> +
> /* The current path: */
> struct strbuf path;
Another thing I noticed: the name of this option,
`iterate_dirs_after_files`, is a little bit misleading. If I understand
correctly, it doesn't make the iteration process files before
directories within a single directory; rather, it ensures that
subdirectories and their contents are processed before the containing
directory. Therefore, a better name might be something like "depth_first".
I should mention that I like the overall idea to add this new feature
and use it to simplify `remove_subtree()`.
Michael
