From: Semen Vadishev Date: Wed, 18 Apr 2012 14:34:30 GMT Subject: Re: Delete gitlink entry but keep .gitmodules file unmodified Message-ID: <4F8ED0F6.5070106@tmatesoft.com> In-Reply-To: <4F8EC4E2.6070507@web.de> > 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). We assume such modifications are rare enough, so this downside is fairly minor in our case. And what about these obsolete [submodule "foo"] sections left in .gitmodules and .git/config files? Do they bring any problems? Maybe for some older git versions? Thank you, Semen Vadishev, TMate Software, http://subgit.com/ - git+svn on the server side! On 4/18/12 17:42, Jens Lehmann wrote: > 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).