Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well

[Junio C Hamano <gitster@pobox.com>]

Jens Lehmann <Jens.Lehmann@web.de> writes:

> Please don't attach your patches, see Documentation/SubmittingPatches on
> how to post patches to this list.
>
> Am 04.03.2013 09:41, schrieb Eric Cousineau:
>> In this patch, foreach --recursive acts depth-first, much like the default
>> behavior described in the patch by Imram Yousuf in this
>> post <http://marc.info/?l=git&m=121066084508631&w=2>.
>> Changes were made so that the submodule "Entering ..." message was right
>> next to the output generated by the command too.
>> It also adds the --parent option for executing the command in the
>> supermodule as well.
>
> From reading the linked pages I assume a valid use case you have is:
>
>    git submodule foreach --recursive 'git add -A && git commit ...'
>
> This will currently not work because the depth first algorithm of foreach
> will execute the command /before/ recursing deeper. You'd need it to
> execute the command /after/ returning from the deeper level (which is what
> your patch seems to be about).
> ...
> What we currently get from your example is:
>   Entering 'a'
>   Entering 'a/b'
>   Entering 'a/b/d'
>   ...
>   Entering 'c'
>   Entering 'd'
> Me thinks this is what most users would expect of a recursion, enter each
> level before descending into the next.
>
> For your use case you'd need to have:
>   Entering 'a/b/d'
>   Entering 'a/b'
>   Entering 'a/c'
>   ...
>   Entering 'c'
>   Entering 'd'
> (Please note that this is still depth-first)
>
> I won't object to adding an option to foreach that will execute the command
> after recursing (but I'm not convinced --parent is a very good name for that).

Are you comparing pre-order vs post-order traversal?

Both can be useful depending on what you are trying to achieve.  You
need a pre-order traversal (i.e. you "visit" and perform some action
on the node and then descend into its children) if you need to do
some preparation before you visit deeper levels; you need a
post-order traversal (i.e. you "visit" and perform some action on
the node after you have done all its children) if you know you will
be readly only after you are done with all your children.

You can throw in in-order traversal to the mix (i.e. you "visit" and
perform some action on the node after visiting some but not all of
your children and then continue visiting the remainder of your
children), but I do not know what practical value you would get out
of it.

So if you want a single boolean to toggle between the current
behaviour and the other one, it would be --post-order.  But you may
at least want to consider pros and cons of allowing users to give
two separate commands, one for the pre-order visitation (which is
the current "command") and the other for the post-order
visitation. Being able to run both might turn out to be useful.