Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 5, 2013, 16:09 UTC
- Message-ID
- <7vhakpvnex.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130305075901.GB4677@sandbox-ub>
Heiko Voigt <hvoigt@hvoigt.net> writes:
Show 26 quoted lines
> On Mon, Mar 04, 2013 at 03:00:45PM -0800, Junio C Hamano wrote: >> 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. > > I second that. Having a --post-order=<command/script> switch will give > us much more flexibility. For ease of use we could allow --post-order > without command to switch the meaning of the main command. > > So a final solution would have these switches: > > git submodule foreach ... [--pre-order[=<command>]] [--post-order[=<command>]] [<command>] > > If only --pre-order without argument is given the command will be > executed pre-order. If only --post-order the command will be executed > post-order. If both are given its an error and so on... > > There are some combinations we would need to catch as errors but this > design should allow a step by step implementation: > > 1. just the --post-order switch > 2. --post-order with argument switch > 3. --pre-order (including argument) for symmetry of usage
Yeah, I think I can agree with that direction, and Eric's patch could be that first step of the three-step progression, without painting us into a corner we cannot get out of when we want to advance to 2 and 3 later.
I was more interested in the design aspect and I didn't look at the actual patch text, though.