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

[Junio C Hamano <gitster@pobox.com>]

Nicolas Morey-Chaisemartin <devel-git@morey-chaisemartin.com> writes:

> On 03/30/2011 09:05 PM, Jens Lehmann wrote:
>>> I know it is very intrusive. The main reason for that is I wanted the -f option to always behave the same (meaning throw away changes),
>>> whether the submodule is already on the right commit or not.
>> 
>> Hmm, I don't know if that is a good thing to do. People are used to
>> "git submodule update" to only touch those submodule where the HEAD
>> differs from the commit recorded in the superproject (And I often
>> find myself using "-f" if the command didn't succeed without it).
>> But when using "-f" touches other submodules than not using it the
>> user might experience a rather unpleasant surprise, I'm not sure we
>> want to go that way.
>
> 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?