Brandon Williams <bmw...@google.com> writes:

> The 'submodule.update' config was historically used and respected by the
> 'submodule update' command because update handled a variety of different
> ways it updated a submodule.  As we begin teaching other commands about
> submodules it makes more sense for the different settings of
> 'submodule.update' to be handled by the individual commands themselves
> (checkout, rebase, merge, etc) so it shouldn't be respected by the
> native checkout command.

Soooo... what's the externally observable effect of this change?  Is
it something that can be illustrated in a set of new tests?

IOW does this commit by itself want to change the behaviour of
"submodule update" and existing (indirect) users of unpack-trees?
Or does it want to keep the documented behaviour of "submodule
update" while correcting unintended triggering in other (indirect)
users of unpack-trees of the same machinery that is being removed in
this patch?

> -     switch (sub->update_strategy.type) {
> -     case SM_UPDATE_UNSPECIFIED:
> -     case SM_UPDATE_CHECKOUT:
> -             if (submodule_move_head(ce->name, old_id, new_id, flags))
> -                     return o->gently ? -1 :
> -                             add_rejected_path(o, 
> ERROR_WOULD_LOSE_SUBMODULE, ce->name);
> -             return 0;
> -     case SM_UPDATE_NONE:
> -             return 0;
> -     case SM_UPDATE_REBASE:
> -     case SM_UPDATE_MERGE:
> -     case SM_UPDATE_COMMAND:
> -     default:
> -             warning(_("submodule update strategy not supported for 
> submodule '%s'"), ce->name);
> -             return -1;
> -     }
> +     if (submodule_move_head(ce->name, old_id, new_id, flags))
> +             return o->gently ? -1 :
> +                                add_rejected_path(o, 
> ERROR_WOULD_LOSE_SUBMODULE, ce->name);
> +     return 0;

With this update, we always behave as if update_strategy.type were
either left unspecified or explicitly set to checkout.  Other arms
in this switch (and the other switch too), especially "none", were
not expecting a call to submodule_move_head() to be made, but now
the call is unconditional.



>  }
>  
>  static void reload_gitmodules_file(struct index_state *index,
> @@ -293,7 +282,6 @@ static void reload_gitmodules_file(struct index_state 
> *index,
>                               submodule_free();
>                               checkout_entry(ce, state, NULL);
>                               gitmodules_config();
> -                             git_config(submodule_config, NULL);
>                       } else
>                               break;
>               }
> @@ -308,19 +296,9 @@ static void unlink_entry(const struct cache_entry *ce)
>  {
>       const struct submodule *sub = submodule_from_ce(ce);
>       if (sub) {
> -             switch (sub->update_strategy.type) {
> -             case SM_UPDATE_UNSPECIFIED:
> -             case SM_UPDATE_CHECKOUT:
> -             case SM_UPDATE_REBASE:
> -             case SM_UPDATE_MERGE:
> -                     /* state.force is set at the caller. */
> -                     submodule_move_head(ce->name, "HEAD", NULL,
> -                                         SUBMODULE_MOVE_HEAD_FORCE);
> -                     break;
> -             case SM_UPDATE_NONE:
> -             case SM_UPDATE_COMMAND:
> -                     return; /* Do not touch the submodule. */
> -             }
> +             /* state.force is set at the caller. */
> +             submodule_move_head(ce->name, "HEAD", NULL,
> +                                 SUBMODULE_MOVE_HEAD_FORCE);
>       }
>       if (!check_leading_path(ce->name, ce_namelen(ce)))
>               return;

Reply via email to