On 11/17, Stefan Beller wrote:

Well first you get the warning:

    "cannot remove submodule '%s' because it (or one of "
    "its nested submodules) uses a .git directory"),

and in case a d/f/ conflict arises in a later stage (e.g. when the submodule
is replaced by a file or symlink), you get another related error with
less helpful description how to debug it.

Maybe a warning isn't the right thing?  Shouldn't the checkout fail if
there are any issues?  This would force the user to stash/commit their
changes and then retry.

quoted

 All other submodules will actually be removed? Couldn't
you end up in an undesirable state with a checkout effecting one
submodule but not another?

Yes you could. Maybe it's time to add
"git submodule intern-git-dir", which can be given as a helpful hint
or even run here first.

That would be a good idea, does that functionality already exist in one
form or another?  I'm assuming it must since git update does just that
when cloning a submodule.

-- 
Brandon Williams