Re: [PATCH] - Added recurse command to git submodule

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

"Lars Hjemli" <hjemli@gmail.com> writes:

> A possible extension is to specifiy "inter-submodule" paths to the
> init subcommand, i.e. for a possible KDE layout:
>   git submodule -r init kdelibs kdelibs/admin
>
> This should then recursively initialize the kdelibs submodule and the
> admin-submodule (in the kdelibs submodule).

Beautiful.

> Btw: from my reading of the code, the git-command specified for
> 'recurse' will be done top-to-bottom: I guess that's what you want for
> something like 'git submodule recurse diff', but not for something
> like 'git submodule recurse commit' (but IMHO the latter one should
> never be executed ;-)

Thanks for raising a very good point.  Yes, some commands
inherently wants depth first.

While I agree that making a recursive is a grave usage error
(submodule commit and toplevel commit are logically different
events and even their commit log message should be different, as
they talk about changes in logically different levels) from
project management point of view, I do not think it is something
a tool has to explicitly forbid the users to do.  I view it as a
kind of a long rope, a misuse the users can be allowed to
inflict on themselves if they really wanted to.

Also, some commands cannot be made recursive by driving them
from a higher level recursive wrapper.  "git submodule recursive
log" would not make much sense, not only because the order of
the log entries are output from different invocations would not
be useful, but because the revision range specifier would need
to be different in different submodules (e.g. library submodules
and application submodule will not share version name namespace,
i.e. "log v1.0..v2.0" is undefined, and worse yet, running "log
v1.0:path/to/sub..v2.0:path/to/sub" in a submodule when running
"log v1.0..v2.0" in the toplevel is not a correct solution
either in general).