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”.

Are we waiting to land this series (or a successor) before starting on
a fix for this issue?  There have been a number of submodule series in
flight recently, and I'm having trouble keeping track of them all ;).

> *) 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 ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy