"Lars Hjemli" <hjemli@xxxxxxxxx> 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). - 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
