Jens Lehmann <Jens.Lehmann@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html