Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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.
And similarly, it might be a good idea to make the presense of "--recursive"
a bit stronger than the command line that did not say either "--recursive"
nor "--no-recursive", so that a subcommand that normally inspects the
state of the submodule and decide to recurse (or not) can be told to
always recurse into it.
If we follow that line of thought, it may make more sense not to implement
your feature like the above patch, but instead make it so
if the user told us never to recurse
then
nothing
elif the user told us to always recurse ||
subsha1 != sha1
then
do the "recurse" thing
fi
so that you can still force it recurse into the submodule, even when you
do not necessarily want the "force checkout" thing to happen to clobber
the working tree.
--
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