Re: submodule update --force

From: Junio C Hamano <gitster@pobox.com>
Date: May 10, 2012, 05:47 UTC
Message-ID: <7vobpwpoyi.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAHOQ7J9xCYL=x=_nbq-3ksC2nF7L0=kxu9JX6M60xM-Bxmyfag@mail.gmail.com>

Stefan Zager <szager@google.com> writes:

Show 31 quoted lines

> I'd like to propose amending the documentation thusly:
>
> According to the docs:
>
>        -f, --force
>            This option is only valid for add and update commands. When
> running add, allow adding an otherwise ignored
>            submodule path. When running update, throw away local
> changes in submodules when switching to a different
>            commit; if not switching to a different commit, a checkout
> to HEAD will still be run.
>
> ... and here's the patch to implement it:
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 64a70d6..8b045d9 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -536,7 +536,7 @@ Maybe you want to use 'update --init'?")"
>                         die "$(eval_gettext "Unable to find current
> revision in submodule path '\$sm_path'")"
>                 fi
>
> -               if test "$subsha1" != "$sha1"
> +               if test "$subsha1" != "$sha1" -o -n "$force"
>                 then
>                         subforce=$force
>                         # If we don't already have a -f flag and the
> submodule has never been checked out
>
> Thoughts?

Even though I admit that I do not use submodule heavily myself, I think this is a sane thing to do. After all, the user explicitly said "I want to force update it", and it is a strong sign that what is in the working tree is suspect and the user wants to make sure everything is in sync.

This is a tangent, but what strikes me odd with the code before this patch is that the decision to recurse into the submodule repository is made solely on the status of the submodule, and there is no way for the user to say "I do not want it to recurse" (in other words, "--recursive" option from the command line does not have any effect on this part of the code).

Perhaps that is because we consider submodules that have been "init"ed always interesting, and if that is the case that may not be a big deal, but it might not be a bad idea to allow "--no-recursive" option to mean something stronger than not giving --recursive option, i.e. not recursing in a situation where it normally would even when run without --recursive.