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
Attachment:
signature.asc
Description: OpenPGP digital signature