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