From: Nicolas Morey-Chaisemartin <devel-git@morey-chaisemartin.com>
Date: Thu, 31 Mar 2011 02:20:33 GMT
Subject: Re: [PATCH] submodule: Add --force option for git submodule update
Message-ID: <4D93E4F1.70103@morey-chaisemartin.com>
In-Reply-To: <7vd3l8mi3m.fsf@alter.siamese.dyndns.org>

On 03/30/2011 11:08 PM, Junio C Hamano wrote:
> 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.
> 

I did. Thee reason is we commit file generated by compilation.
Whether it's docs, references (for automated integration) or simply result files that take 2 days to build,
we have a strong need to commit generated files.
And in this case, we need to discard a lot of things very often.

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

I agree. A git submodule reset command makes a lot of sense.
But I also still think having a --force option to update does too, in the way Jens proposed it (only on submodule that actually needed a checkout), don't you?