Re: submodule update --force
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:48
Stefan Zager [off-list ref] writes:
quoted hunk
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 currentrevision 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.