On Thu, May 10, 2012 at 2:57 PM, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote:
>
> 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.
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.
> 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.
(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.
Regards,
Phil
--
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