On Wed, May 9, 2012 at 11:18 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > If we follow that line of thought, it may make more sense not to implement > your feature like the above patch, but instead make it so > > if the user told us never to recurse > then > nothing > elif the user told us to always recurse || > subsha1 != sha1 > then > do the "recurse" thing > fi > > so that you can still force it recurse into the submodule, even when you > do not necessarily want the "force checkout" thing to happen to clobber > the working tree. I'm a bit confused by your use of the term recursion here. It sounds like you consider any operation run on a submodule to be a form of recursion, which is not the way I think about it. 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. I think your solution would work for our project, because we only use one level of submodules. But IMO the functionality, as you have written it, is less generally useful. Stefan -- 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