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

From: Phil Hord <phil.hord@gmail.com>
Date: Mar 12, 2013, 16:01 UTC
Message-ID: <CABURp0qBA6myf7_SuaxJSrePJHmh2v-nmtLRzKTtgAJxLkJ-tQ@mail.gmail.com>
In-Reply-To: <513B7D08.20406@web.de>

On Sat, Mar 9, 2013 at 1:18 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:

Show 46 quoted lines

> Am 05.03.2013 22:17, schrieb Phil Hord:
>> On Tue, Mar 5, 2013 at 3:51 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>>> Am 05.03.2013 19:34, schrieb Junio C Hamano:
>>>> Eric Cousineau <eacousineau@gmail.com> writes:
>>>>> ...
>>>> I am not entirely convinced we would want --include-super in the
>>>> first place, though.  It does not belong to "submodule foreach";
>>>> it is doing something _outside_ the submoudules.
>>>
>>> I totally agree with that. First, adding --include-super does not
>>> belong into the --post-order patch at all, as that is a different
>>> topic (even though it belongs to the same use case Eric has). Also
>>> the reason why we are thinking about adding the --post-order option
>>> IMO cuts the other way for --include-super: It is so easy to do
>>> that yourself I'm not convinced we should add an extra option to
>>> foreach for that, especially as it has nothing to do with submodules.
>>> So I think we should just drop --include-super.
>>
>> I agree it should not be part of this commit, but I've often found
>> myself in need of an --include-super switch.   To me,
>> git-submodule-foreach means "visit all my .git repos in this project
>> and execute $cmd".  It's a pity that the super-project is considered a
>> second-class citizen in this regard.
>
> Hmm, for me the super-project is a very natural second-class citizen
> to "git *submodule* foreach". But also I understand that sometimes the
> user wants to apply a command to superproject and submodules alike (I
> just recently did exactly that with "git gc" on our build server).
>
>> I have to do this sometimes:
>>
>>    ${cmd} && git submodule foreach --recursive '${cmd}'
>>
>> I often forget the first part in scripts, though, and I've seen others
>> do it too.  I usually create a function for it in git-heavy scripts.
>>
>> In a shell, it usually goes like this:
>>
>>    git submodule foreach --recursive '${cmd}'
>>    <up><home><del>{30-ish}<end><backspace><enter>
>>
>> It'd be easier if I could just include a switch for this, and maybe
>> even create an alias for it.  But maybe this is different command
>> altogether.
>
> Are you sure you wouldn't forget to provide such a switch too? ;-)

No. However, when I remember to add the switch, my shell history will remember it for me. This does not happen naturally for me in the "<up><home><del>{30-ish}..." workflow.

I also hope this switch grows up into a configuration option someday. Or maybe a completely different command, like I said before; because I actually think it could be dangerous as a configuration option since it would have drastic consequences for users executing scripts or commands in other users' environments.

Show 6 quoted lines

> I'm still not convinced we should add a new switch, as it can easily
> be achieved by adding "${cmd} &&" to your scripts. And on the command
> line you could use an alias like this one to achieve that:
>
> [alias]
>         recurse = !sh -c \"$@ && git submodule foreach --recursive $@\"

Yes, making the feature itself a 2nd-class citizen.  :-)

But this alias also denies me the benefit of the --post-order option. For 'git recurse git push', for example, I wouldn't want the superproject push to occur first; I would want it to occur last after the submodules have been successfully pushed.

I agree this should go in some other commit, but I do not think it is so trivial it should never be considered as a feature for git. That's all I'm trying to say.

Phil