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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 30, 2011, 21:08 UTC
Message-ID: <7vd3l8mi3m.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4D93905E.5030806@morey-chaisemartin.com>

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

Show 18 quoted lines

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