Re: [PATCH] submodule: Add --force option for git submodule update

> Nicolas Morey-Chaisemartin <devel-git@morey-chaisemartin.com> writes:
>> Well I was'nt sure about it either.
>> The idea for me was to be able to put the repo and submodules in the cloned state (except for ignored files)
>> In the current version the right thing to do is a bit of a mess:
>> $ git submodule foreach --recursive 'git checkout -f HEAD'
>> $ git submodule foreach --recursive 'git clean -f' # An untracked file on HEAD may be overwrittent by the new HEAD so checkout may fail if you don't do that
>> $ git submodule update --recursive
> 
> Shouldn't you be questioning _why_ your users have such changes that
> require them to run "checkout -f" everywhere in the submodule forests and
> still want to run "submodule update" in the first place?  If it happens
> very often and your users are constantly discarding what they have half
> accomplished, there is something wrong with the way your project works.
> 

> If we read your motivation section in your original,
> 
>   > This implies that to reset a whole git submodule tree, a user has to run
>   > first 'git submodule foreach --recursive git checkout -f' to then be
>   > able to run git submodule update.
> 
> this is about "resetting", i.e. throwing away the work.  I think that is a
> sensible thing to do, but it is a very different purpose than "updating
> submodules so that I can work on top of what other people did", which
> would happen a lot more often than that.
> 
> Wouldn't it be both safer and easier to understand for the users if this
> "obliterate all my uncommitted work" were a separate subcommand, e.g. "git
> submodule reset --recursive" or something?
>