Re: [RFC/PATCH 2/4] Submodules: Add the lib-submodule-update.sh test library

> On Tue, Mar 25, 2014 at 06:05:05PM +0100, Jens Lehmann wrote:
>> *) When a submodule is replaced with a tracked file of the same name
>>    the submodule work tree including any local modifications (and
>>    even the whole history if it uses a .git directory instead of a
>>    gitfile!) is simply removed.
>> …
>> I think the first bug really needs to be fixed, as that behavior is
>> extremely nasty. We should always protect work tree modifications
>> (unless forced) and *never* remove a .git directory (even when
>> forced).
> 
> I think this should be covered by the usual “don't allow checkouts
> from dirty workdirs unless the dirty-ing changes are easily applied to
> the target tree”.

>> *) Forced work tree updates happily manipulate files in the
>>    directory of a submodule that has just been removed in the
>>    superproject (but is of course still present in the work tree due
>>    to the way submodules are currently handled). This becomes
>>    dangerous when files in the submodule directory are overwritten
>>    by files from the new superproject commit, as any modifications
>>    to the submodule files will be lost) and is expected to also
>>    destroy history in the - admittedly unlikely case - the new
>>    commit adds a file named ".git" to the submodule directory.
>> …
>> I'm not so sure about the second one. Even though I believe the
>> current behavior is not correct (switching commits should never mess
>> around in a submodule directory)
> 
> This should also be covered by the usual “don't allow checkouts from
> dirty workdirs unless the dirty-ing changes are easily applied to the
> target tree”.  We don't implement this yet, but I'd like to force
> users to move any about-to-be-clobbered state from their submodule
> into .git/modules/<name>/ (via commits or stashes) before allowing
> them to begin the checkout.  Once we've ensured that the state is
> preserved out-of-tree, then clobber away ;).