From: Philippe Blain <email@example.com> To: Kaartic Sivaraam <firstname.lastname@example.org> Cc: Luke Diamand <email@example.com>, Git mailing list <firstname.lastname@example.org>, Jens Lehmann <Jens.Lehmann@web.de> Subject: Re: How to checkout a revision that contains a deleted submodule? Date: Mon, 21 Sep 2020 19:14:41 -0400 [thread overview] Message-ID: <FFBB71FD-8D1F-4E86-9E37-813018AFC690@gmail.com> (raw) In-Reply-To: <email@example.com> Hi Luke and Kaartic, > Le 20 sept. 2020 à 14:02, Kaartic Sivaraam <firstname.lastname@example.org> a écrit : > > On 20/09/20 3:14 pm, Luke Diamand wrote: >> On Sat, 19 Sep 2020 at 10:03, Luke Diamand <email@example.com> 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 firstname.lastname@example.org: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 don't think that part of the documentation applies to your case. I also don't think this part of the doc applies here. > So, > I also don't think this is a known bug. As a matter of fact, I couldn't > reproduce this with the following: > > > git init checkout-removed-submodule && > cd checkout-removed-submodule/ && > echo "Hello, world" >foo && > git add foo && git commit -m "Initial commit" && > git init ../submodule && > cd ../submodule/ && > echo "Foo bar" >foobar.txt && > git add foobar.txt && git commit -m "Foo bar baz" && > cd ../checkout-removed-submodule/ && > git submodule add ../submodule/ foobar && > git commit -m "Add foobar submodule" && > git rm foobar/ && > git commit -m "Remove foobar submodule" && > git checkout HEAD~ # Checking out the "Add foobar submodule" commit Yes. At this point "foobar" would be empty because '--recurse-submodules' was not used on 'checkout'. Using `git checkout --recurse-submodules HEAD~` instead would populate it, and it would work correctly because the Git repository of foobar does exist at .git/modules/foobar. > I also tried with a cloned version of that repository as follows: here let's make sure we re-checkout 'master' before cloning: git checkout - > git clone /me/checkout-removed-submodule/ cloned-repo && > cd cloned-repo && > git co HEAD~ > > I get: > > HEAD is now at 25270d8 Add foobar submodule I get the same thing, with or without '--recurse-submodules'. However, if I you have the 'submodule.active' configuration set to '.', which is the case if you *cloned* with '--recurse-submodules', and you then checkout with '--recurse-submodules', then it fails as Luke describes: git clone --recurse-submodules checkout-removed-submodule cloned-repo cd cloned-repo && git co --recurse-submodules HEAD~ fatal: not a git repository: ../.git/modules/foobar fatal: could not reset submodule index This bug was reported earlier in May , and I suggested a couple ways the experience could be improved. I might add here that maybe a good idea would be that 'checkout' be taught to try to clone the missing submodules if it does not find their repository at .git/modules. Cheers, Philippe.  https://email@example.com/T/#u
next prev parent reply other threads:[~2020-09-21 23:14 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-19 9:03 Luke Diamand 2020-09-20 9:44 ` Luke Diamand 2020-09-20 18:02 ` Kaartic Sivaraam 2020-09-20 20:52 ` Luke Diamand 2020-09-21 23:14 ` Philippe Blain [this message] 2020-09-22 4:32 ` Luke Diamand 2020-09-21 22:46 ` Philippe Blain
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=FFBB71FD-8D1F-4E86-9E37-813018AFC690@gmail.com \ --firstname.lastname@example.org \ --cc=Jens.Lehmann@web.de \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: How to checkout a revision that contains a deleted submodule?' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).