git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Heiko Voigt <hvoigt@hvoigt.net>
Cc: Jens Lehmann <Jens.Lehmann@web.de>,
	Eric Cousineau <eacousineau@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
Date: Tue, 05 Mar 2013 08:09:26 -0800	[thread overview]
Message-ID: <7vhakpvnex.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20130305075901.GB4677@sandbox-ub> (Heiko Voigt's message of "Tue, 5 Mar 2013 08:59:02 +0100")

Heiko Voigt <hvoigt@hvoigt.net> writes:

> 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.

  reply	other threads:[~2013-03-05 16:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-04  8:41 [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well Eric Cousineau
2013-03-04 22:15 ` Jens Lehmann
2013-03-04 23:00   ` Junio C Hamano
2013-03-05  5:37     ` Eric Cousineau
2013-03-05  7:59     ` Heiko Voigt
2013-03-05 16:09       ` Junio C Hamano [this message]
2013-03-05 16:42         ` Eric Cousineau
2013-03-05 18:34           ` Junio C Hamano
2013-03-05 20:51             ` Jens Lehmann
2013-03-05 21:17               ` Phil Hord
2013-03-09 18:18                 ` Jens Lehmann
2013-03-11 16:46                   ` Heiko Voigt
2013-03-12 16:01                   ` Phil Hord
2013-03-14  6:30                     ` Eric Cousineau
2013-03-18 21:25                       ` Jens Lehmann
2013-03-26  4:03                         ` Eric Cousineau
2013-04-02 20:14                           ` Jens Lehmann
2013-04-13  4:04                             ` [PATCH] submodule foreach: Added in --post-order=<command> and adjusted code per Jens Lehmann's suggestions eacousineau
     [not found]                               ` <CA+aSAWuK9Yhvx-vO1fUteq-K=xOPgxkyeWeHG3UwZuDHsxLzAw@mail.gmail.com>
2013-04-13  4:11                                 ` Eric Cousineau
2013-04-14 18:52                               ` Jens Lehmann
2013-03-18 21:10                     ` [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well Jens Lehmann
2013-03-26  3:56                       ` Eric Cousineau
2013-03-26  4:36                         ` Eric Cousineau
2013-03-26  5:23                       ` Junio C Hamano
2013-03-26  5:25                         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vhakpvnex.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Jens.Lehmann@web.de \
    --cc=eacousineau@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=hvoigt@hvoigt.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).