Re: How to checkout a revision that contains a deleted submodule?
- From
Luke Diamand <luke@diamand.org>
- Date
- Sep 20, 2020, 09:44 UTC
- Message-ID
- <CAE5ih79puooMA1v8jOkqKaO9xPmYqtkT9kXHq2L6YODJJ8oGEQ@mail.gmail.com>
- In-Reply-To
- <CAE5ih78zCR0ZdHAjoxguUb3Y6KFkZcoxJjhS7rkbtZpr+d1n=g@mail.gmail.com>
On Sat, 19 Sep 2020 at 10:03, Luke Diamand <luke@diamand.org> wrote:
Show 32 quoted lines
> > 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@my.repo: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
Show 8 quoted lines
> 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