Am 18.04.2012 15:19, schrieb Semen Vadishev: > Suppose one has a properly initialized submodule in a tree like this: > > $ git ls-tree HEAD > 100644 blob d208248ba4ab1d1791dc27f451dcaedb87dc19e1 .gitmodules > 160000 commit ec633ea81e3cf64c3735ef4acd5ff9a490ed54eb ext > 100644 blob 597d6924118c00054efd526d9e48f68198f7da12 file.txt > > $ git show HEAD:.gitmodules > [submodule "ext"] > path = ext > url = $URL > > Then one pulls a modification that replaces 'ext' gitlink by some blob or tree entry, but keeps '.gitmodules' the same: > > $ git ls-tree HEAD > 100644 blob d208248ba4ab1d1791dc27f451dcaedb87dc19e1 .gitmodules > 040000 tree 82e3a754b6a0fcb238b03c0e47d05219fbf9cf89 ext > 100644 blob 597d6924118c00054efd526d9e48f68198f7da12 file.txt > > Are there any possible downsides of such modification we should be aware of? Yes, unfortunately current git isn't able to do that (even though work is ongoing to make future versions handle that just fine). Right now the populated submodule "ext" won't be removed when you switch to a branch where it doesn't exist. If the new branch has a tree there, you'll almost certainly get an error when trying to switch to it as that would overwrite files left over from the submodule (end even if it doesn't, you'll might get lots of untracked files in the tree after the checkout). As a workaround you could use a symbolic link (assuming you FS supports that) and switch that around between two different directories: 100644 .gitmodules 100644 ext -> ext_sub 160000 ext_sub 100644 .gitmodules 100644 ext -> ext_tree 160000 ext_tree If you then add ext_sub and ext_tree to the .gitignore of each side it isn't present in, everything should work just fine (and when git learns to handle that case, you can get rid of that workaround for future commits). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html