Re: submodule update --force

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Zager <szager@xxxxxxxxxx> writes:

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]