Hi, On Fri, May 11, 2012 at 04:56:07PM -0400, Phil Hord wrote: > On Thu, May 10, 2012 at 2:57 PM, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote: > > 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. > > Do I understand you to mean that you think the git-submodule ... > --recursive option is archaic? I would agree that one might expect it > to be the default option, but I do not think it should be deprecated > in any way. In a way yes its archaic since I do not know why one would distinguish between the first level of populated submodules and below. For example if you have nested submodules and want them all be populated you need to use git submodule update --init --recursive The sequence git submodule init --recursive git submodule update --recursive does not do the same thing but would have to be called multiple times until you have reached the deepest level. IMO that is confusing but not only a problem of this option. > > 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? > > I think there are three cases: > > 1. I want to update any sha1-mismatching submodules so > their HEAD matches the superproject gitlink. > > git submodule update > > 2. Same as (1) above, but also check out files for all > submodules which are not already checked out. > > git submodule update && > git submodule foreach 'git checkout HEAD || :' > > 3. I want to update exactly to the gitlinks in the superproject > and discard any local or staged changes. > > git submodule update -f > > (2) above is the case Junio was trying to cover. I cannot think of an > elegant name for the switch for such an option, but I would be > surprised it to find it is not the default behavior if I also > encountered it like Stefan did. We should try to eliminate surprises > to help dispel the notion that submodules are unwieldy. Yes we should eliminate surprises thats true. On the other hand there is no way to setup submodules in the way Stefan had them by using the git submodule command or is there? So for his use case the command sequence you described seems to be more appropriate but I am not sure whether that justifies a separate option for it. > (3) is too heavy when I really only wanted (2). > > I do not understand that use case that led Stefan to the predicament > he was in where he had submodules with HEADs but with no checked out > files. But I do not begrudge his being there. Yes, but currently -f is wrong in the way that when the submodules HEAD sha1 is the same as registered in the superproject it will skip the checkout. That is wrong when you have local uncommitted changes in the worktree. In such a state I would expect it to throw away those local changes and checkout HEAD. So I think Stefans patch makes sense anyway even though it might actually be to heavy for his use case. 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