Re: submodule update --force

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 [off-list ref] wrote:

quoted

On Thu, May 10, 2012 at 07:58:09AM -0700, Junio C Hamano wrote:

quoted

Stefan Zager [off-list ref] writes:

quoted

... ?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.

quoted

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