Hallo all, On Thu, May 10, 2012 at 07:58:09AM -0700, Junio C Hamano wrote: > Stefan Zager <szager@xxxxxxxxxx> writes: > > > ... To my mind, any > > `git submodule` command should *always* run on the first level of > > submodules. If you're going to specify --no-recurse, then why are you > > running `git submodule` at all? I think 'recursion' only applies to > > moving beyond the first level of submodules. > > Very true. > > Submodule folks, any opinion on the Stefan's approach? The distinction between first level of submodules and deeper is only present in the "git submodule" subcommand and I think mainly for historical reasons. I do not see a use case where this would be helpful. To skip uninteresting submodules one can always use the submodule.$name.update option set to 'none'. (I just found that its documentation is in the wrong place but I will send a seperate patch about that). In the non submodule commands we usually name this option --recurse-submodules=always and have another --recurse-submodules=on-demand option for the current behavior. Those options would either recurse or do nothing with the submodule. Such a behavior, as pointed out, does not make sense for 'submodule update'. Similar options names for 'submodule update' would probably be --recurse=always and --recurse=on-demand. Nonetheless is force a term where the user probably wants to skip all optimizations which the sha1 equality provides. So to make the current behavior more consistent I would be fine with adding this change. One thing which might make force even more useful would be to also skip the "is the sha1 available"-check for fetch that is possibly run before the checkout and just always run the fetch. In the long term, once checkout has learned things 'submodule update' is currently doing, it probably makes sense to let 'submodule update' always recurse into all checked out submodules. Since then it does not make sense to run 'submodule update' for much more than resetting things or changing the currently registered commits anymore. So in the bright new future the 'on-demand' part will probably move away from 'submodule update' and as such it does not make sense to implement the seperate recurse options I described above. What do others think? Cheers Heiko -- 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