On Sat, 19 Sep 2020 at 10:03, Luke Diamand <luke@xxxxxxxxxxx> wrote: > > Maybe this is a FAQ, but I couldn't figure it out! > > I have a repo which has a couple of submodules. > > At some point in the past I deleted one of those submodules: > > git rm sub2 > git add -u > git commit -m 'Deleting sub2' > git push origin > ... > ... more commits and pushes... > > Now I go and clone the head revision. This gives me a clone which has > nothing present in .git/modules/sub2. > login on some other machine > git clone git@xxxxxxx:thing > cd thing > ls .git/modules > <sub2 not present> > > So when I go and checkout an old revision where sub2 is still around I get: > git checkout oldrevision > fatal: not a git repository: sub2/../.git/modules/sub2 > > What am I doing wrong? > What set of commands do I need to use to ensure that this will always > do the right thing? > > Thanks > Luke Replying to myself, adding Jens who added the section below. This is a known bug: https://git-scm.com/docs/git-rm > BUGS > ---- > Each time a superproject update removes a populated submodule > (e.g. when switching between commits before and after the removal) a > stale submodule checkout will remain in the old location. Removing the > old directory is only safe when it uses a gitfile, as otherwise the > history of the submodule will be deleted too. This step will be > obsolete when recursive submodule update has been implemented. I'm wondering what "recursive submodule update" is. If I do: git submodule update --checkout --force --remote --recursive then those stale repos are still left lying around. I guess that's a different kind of recursive? Thanks Luke
