On Jan 10, 2008 2:26 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "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. Firstly, thank you for the feedback Junio and Lars. Secondly, I was not planning to add recurse to the init/update command, but your (Lars) suggestion seems really handy; I will implement it in my patch. About auto-initialization, I, as writing, am implementing it to be optional and an extra -i has to be specified if the user wants to do it. > > > 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. > I could not agree more and in fact, I wanted to leave to the user how they use the recurse command. I basically will be using for status and diff primarily; and may be for creating and checking out branches; but as I said it mostly depends on how the user wants to use it. > 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. > In fact if I am also thinking whether to add intelligence in such scenarios. What do you think if we choose DF of BF based on the command and options? > 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). > What is you suggestion in such cases Junio? > -- Imran M Yousuf - 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
