{"thread":{"id":"54261","subject":"How to checkout a revision that contains a deleted submodule?","startedAt":"2020-09-19T09:04:55Z","lastAt":"2020-09-22T04:33:12Z","messageCount":7,"participants":["Luke Diamand","Kaartic Sivaraam","Philippe Blain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"405933","messageId":"CAE5ih78zCR0ZdHAjoxguUb3Y6KFkZcoxJjhS7rkbtZpr+d1n=g@mail.gmail.com","threadId":"54261","inReplyTo":null,"subject":"How to checkout a revision that contains a deleted submodule?","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2020-09-19T09:03:57Z","receivedAt":"2020-09-19T09:04:55Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"Maybe this is a FAQ, but I couldn't figure it out!\n\nI have a repo which has a couple of submodules.\n\nAt some point in the past I deleted one of those submodules:\n\n git rm sub2\n git add -u\n git commit -m 'Deleting sub2'\n git push origin\n ...\n ... more commits and pushes...\n\nNow I go and clone the head revision. This gives me a clone which has\nnothing present in .git/modules/sub2.\n login on some other machine\n git clone git@my.repo:thing\n cd thing\n ls .git/modules\n \n\nSo when I go and checkout an old revision where sub2 is still around I get:\n git checkout oldrevision\n fatal: not a git repository: sub2/../.git/modules/sub2\n\nWhat am I doing wrong?\nWhat set of commands do I need to use to ensure that this will always\ndo the right thing?\n\nThanks\nLuke\n"},{"id":"405977","messageId":"CAE5ih79puooMA1v8jOkqKaO9xPmYqtkT9kXHq2L6YODJJ8oGEQ@mail.gmail.com","threadId":"54261","inReplyTo":"CAE5ih78zCR0ZdHAjoxguUb3Y6KFkZcoxJjhS7rkbtZpr+d1n=g@mail.gmail.com","subject":"Re: How to checkout a revision that contains a deleted submodule?","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2020-09-20T09:44:05Z","receivedAt":"2020-09-20T09:44:22Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"On Sat, 19 Sep 2020 at 10:03, Luke Diamand wrote:\n>\n> Maybe this is a FAQ, but I couldn't figure it out!\n>\n> I have a repo which has a couple of submodules.\n>\n> At some point in the past I deleted one of those submodules:\n>\n> git rm sub2\n> git add -u\n> git commit -m 'Deleting sub2'\n> git push origin\n> ...\n> ... more commits and pushes...\n>\n> Now I go and clone the head revision. This gives me a clone which has\n> nothing present in .git/modules/sub2.\n> login on some other machine\n> git clone git@my.repo:thing\n> cd thing\n> ls .git/modules\n> \n>\n> So when I go and checkout an old revision where sub2 is still around I get:\n> git checkout oldrevision\n> fatal: not a git repository: sub2/../.git/modules/sub2\n>\n> What am I doing wrong?\n> What set of commands do I need to use to ensure that this will always\n> do the right thing?\n>\n> Thanks\n> Luke\n\nReplying to myself, adding Jens who added the section below.\n\nThis is a known bug:\n\nhttps://git-scm.com/docs/git-rm\n\n> BUGS\n> ----\n> Each time a superproject update removes a populated submodule\n> (e.g. when switching between commits before and after the removal) a\n> stale submodule checkout will remain in the old location. Removing the\n> old directory is only safe when it uses a gitfile, as otherwise the\n> history of the submodule will be deleted too. This step will be\n> obsolete when recursive submodule update has been implemented.\n\nI'm wondering what \"recursive submodule update\" is. If I do:\n\n git submodule update --checkout --force --remote --recursive\n\nthen those stale repos are still left lying around. I guess that's a\ndifferent kind of recursive?\n\nThanks\nLuke\n"},{"id":"405998","messageId":"4eb688f2-0c17-9b85-e60e-f07485895622@gmail.com","threadId":"54261","inReplyTo":"CAE5ih79puooMA1v8jOkqKaO9xPmYqtkT9kXHq2L6YODJJ8oGEQ@mail.gmail.com","subject":"Re: How to checkout a revision that contains a deleted submodule?","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2020-09-20T18:02:51Z","receivedAt":"2020-09-20T18:02:56Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On 20/09/20 3:14 pm, Luke Diamand wrote:\n> On Sat, 19 Sep 2020 at 10:03, Luke Diamand wrote:\n>>\n>> Maybe this is a FAQ, but I couldn't figure it out!\n>>\n>> I have a repo which has a couple of submodules.\n>>\n>> At some point in the past I deleted one of those submodules:\n>>\n>> git rm sub2\n>> git add -u\n>> git commit -m 'Deleting sub2'\n>> git push origin\n>> ...\n>> ... more commits and pushes...\n>>\n>> Now I go and clone the head revision. This gives me a clone which has\n>> nothing present in .git/modules/sub2.\n>> login on some other machine\n>> git clone git@my.repo:thing\n>> cd thing\n>> ls .git/modules\n>> \n>>\n>> So when I go and checkout an old revision where sub2 is still around I get:\n>> git checkout oldrevision\n>> fatal: not a git repository: sub2/../.git/modules/sub2\n>>\n>> What am I doing wrong?\n>> What set of commands do I need to use to ensure that this will always\n>> do the right thing?\n>>\n>> Thanks\n>> Luke\n> \n> Replying to myself, adding Jens who added the section below.\n> \n> This is a known bug:\n> \n> https://git-scm.com/docs/git-rm\n> \n>> BUGS\n>> ----\n>> Each time a superproject update removes a populated submodule\n>> (e.g. when switching between commits before and after the removal) a\n>> stale submodule checkout will remain in the old location. Removing the\n>> old directory is only safe when it uses a gitfile, as otherwise the\n>> history of the submodule will be deleted too. This step will be\n>> obsolete when recursive submodule update has been implemented.\n> \n\nI don't think that part of the documentation applies to your case. So,\nI also don't think this is a known bug. As a matter of fact, I couldn't\nreproduce this with the following:\n\n\n git init checkout-removed-submodule &&\n cd checkout-removed-submodule/ &&\n echo \"Hello, world\" >foo &&\n git add foo && git commit -m \"Initial commit\" &&\n git init ../submodule &&\n cd ../submodule/ &&\n echo \"Foo bar\" >foobar.txt &&\n git add foobar.txt && git commit -m \"Foo bar baz\" &&\n cd ../checkout-removed-submodule/ &&\n git submodule add ../submodule/ foobar &&\n git commit -m \"Add foobar submodule\" &&\n git rm foobar/ &&\n git commit -m \"Remove foobar submodule\" &&\n git checkout HEAD~ # Checking out the \"Add foobar submodule\" commit\n\nI get:\n\n HEAD is now at 25270d8 Add foobar submodule\n\n\nI also tried with a cloned version of that repository as follows:\n git clone /me/checkout-removed-submodule/ cloned-repo &&\n cd cloned-repo &&\n git co HEAD~\n\nI get:\n\n HEAD is now at 25270d8 Add foobar submodule\n\nSo, I don't get any errors when I checkout a revision where the deleted\nsubmodule is still around. There might other factors in play such as,\n\n- the version of Git being used\n- whether `--recurse-submodules` was passed to checkout\n- the configuration of the submodule in .gitmodules\n\nIt would be great if you could share these and possibly other useful\ninformation to help us identify why you get an error when checking out\nthe revision.\n\n--\nSivaraam\n"},{"id":"406003","messageId":"CAE5ih78bWJ3BjvJw0=0=ry2OpcT5Dg5ryibw9Cf6pg-xhAJf4Q@mail.gmail.com","threadId":"54261","inReplyTo":"4eb688f2-0c17-9b85-e60e-f07485895622@gmail.com","subject":"Re: How to checkout a revision that contains a deleted submodule?","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2020-09-20T20:52:22Z","receivedAt":"2020-09-20T20:52:36Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"On Sun, 20 Sep 2020 at 19:02, Kaartic Sivaraam\n wrote:\n>\n> On 20/09/20 3:14 pm, Luke Diamand wrote:\n> > On Sat, 19 Sep 2020 at 10:03, Luke Diamand wrote:\n> >>\n> >> Maybe this is a FAQ, but I couldn't figure it out!\n> >>\n> >> I have a repo which has a couple of submodules.\n> >>\n> >> At some point in the past I deleted one of those submodules:\n> >>\n> >> git rm sub2\n> >> git add -u\n> >> git commit -m 'Deleting sub2'\n> >> git push origin\n> >> ...\n> >> ... more commits and pushes...\n> >>\n> >> Now I go and clone the head revision. This gives me a clone which has\n> >> nothing present in .git/modules/sub2.\n> >> login on some other machine\n> >> git clone git@my.repo:thing\n> >> cd thing\n> >> ls .git/modules\n> >> \n> >>\n> >> So when I go and checkout an old revision where sub2 is still around I get:\n> >> git checkout oldrevision\n> >> fatal: not a git repository: sub2/../.git/modules/sub2\n> >>\n> >> What am I doing wrong?\n> >> What set of commands do I need to use to ensure that this will always\n> >> do the right thing?\n> >>\n> >> Thanks\n> >> Luke\n> >\n> > Replying to myself, adding Jens who added the section below.\n> >\n> > This is a known bug:\n> >\n> > https://git-scm.com/docs/git-rm\n> >\n> >> BUGS\n> >> ----\n> >> Each time a superproject update removes a populated submodule\n> >> (e.g. when switching between commits before and after the removal) a\n> >> stale submodule checkout will remain in the old location. Removing the\n> >> old directory is only safe when it uses a gitfile, as otherwise the\n> >> history of the submodule will be deleted too. This step will be\n> >> obsolete when recursive submodule update has been implemented.\n> >\n>\n> I don't think that part of the documentation applies to your case. So,\n> I also don't think this is a known bug. As a matter of fact, I couldn't\n> reproduce this with the following:\n>\n>\n> git init checkout-removed-submodule &&\n> cd checkout-removed-submodule/ &&\n> echo \"Hello, world\" >foo &&\n> git add foo && git commit -m \"Initial commit\" &&\n> git init ../submodule &&\n> cd ../submodule/ &&\n> echo \"Foo bar\" >foobar.txt &&\n> git add foobar.txt && git commit -m \"Foo bar baz\" &&\n> cd ../checkout-removed-submodule/ &&\n> git submodule add ../submodule/ foobar &&\n> git commit -m \"Add foobar submodule\" &&\n> git rm foobar/ &&\n> git commit -m \"Remove foobar submodule\" &&\n> git checkout HEAD~ # Checking out the \"Add foobar submodule\" commit\n>\n> I get:\n>\n> HEAD is now at 25270d8 Add foobar submodule\n>\n>\n> I also tried with a cloned version of that repository as follows:\n> git clone /me/checkout-removed-submodule/ cloned-repo &&\n> cd cloned-repo &&\n> git co HEAD~\n>\n> I get:\n>\n> HEAD is now at 25270d8 Add foobar submodule\n>\n> So, I don't get any errors when I checkout a revision where the deleted\n> submodule is still around. There might other factors in play such as,\n>\n> - the version of Git being used\n> - whether `--recurse-submodules` was passed to checkout\n> - the configuration of the submodule in .gitmodules\n>\n> It would be great if you could share these and possibly other useful\n> information to help us identify why you get an error when checking out\n> the revision.\n\nThanks for taking the time to answer!\n\nI will see if I can come up with a test case.\n\nLuke\n"},{"id":"406100","messageId":"0B191753-C1AD-499C-B8B2-122F49CF6F14@gmail.com","threadId":"54261","inReplyTo":"CAE5ih79puooMA1v8jOkqKaO9xPmYqtkT9kXHq2L6YODJJ8oGEQ@mail.gmail.com","subject":"Re: How to checkout a revision that contains a deleted submodule?","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2020-09-21T22:46:13Z","receivedAt":"2020-09-21T22:46:20Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Luke, \n\n> Le 20 sept. 2020 à 05:44, Luke Diamand a écrit :\n> \n> On Sat, 19 Sep 2020 at 10:03, Luke Diamand wrote:\n>> \n>> Maybe this is a FAQ, but I couldn't figure it out!\n>> \n>> I have a repo which has a couple of submodules.\n>> \n>> At some point in the past I deleted one of those submodules:\n>> \n>> git rm sub2\n>> git add -u\n>> git commit -m 'Deleting sub2'\n>> git push origin\n>> ...\n>> ... more commits and pushes...\n>> \n>> Now I go and clone the head revision. This gives me a clone which has\n>> nothing present in .git/modules/sub2.\n>> login on some other machine\n>> git clone git@my.repo:thing\n>> cd thing\n>> ls .git/modules\n>> \n>> \n>> So when I go and checkout an old revision where sub2 is still around I get:\n>> git checkout oldrevision\n>> fatal: not a git repository: sub2/../.git/modules/sub2\n>> \n>> What am I doing wrong?\n>> What set of commands do I need to use to ensure that this will always\n>> do the right thing?\n>> \n>> Thanks\n>> Luke\n> \n> Replying to myself, adding Jens who added the section below.\n> \n> This is a known bug:\n> \n> https://git-scm.com/docs/git-rm\n> \n>> BUGS\n>> ----\n>> Each time a superproject update removes a populated submodule\n>> (e.g. when switching between commits before and after the removal) a\n>> stale submodule checkout will remain in the old location. Removing the\n>> old directory is only safe when it uses a gitfile, as otherwise the\n>> history of the submodule will be deleted too. This step will be\n>> obsolete when recursive submodule update has been implemented.\n> \n> I'm wondering what \"recursive submodule update\" is. If I do:\n> \n> git submodule update --checkout --force --remote --recursive\n> \n> then those stale repos are still left lying around. I guess that's a\n> different kind of recursive?\n> \n\nI think Jens was referring to this project :\nhttps://github.com/jlehmann/git-submod-enhancements/wiki/Recursive-submodule-checkout\n\nof which some parts were implemented over the years,\na lot of them by Stefan Beller. \n\nIn fact this part of the doc is stale and should be removed since `git checkout` now \nunderstands `--recurse-submodules` and will\nautomatically transform \"old-style\" subdmodules (i.e. with an embeded .git repository)\ninto \"new style\" submodules (with a gitfile) (see gitsubmodules(7), at [1], for more info)\nwhen switching to a commit where the submodule is not present.\n\nCheers,\nPhilippe."},{"id":"406103","messageId":"FFBB71FD-8D1F-4E86-9E37-813018AFC690@gmail.com","threadId":"54261","inReplyTo":"4eb688f2-0c17-9b85-e60e-f07485895622@gmail.com","subject":"Re: How to checkout a revision that contains a deleted submodule?","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2020-09-21T23:14:41Z","receivedAt":"2020-09-21T23:14:47Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Luke and Kaartic,\n\n> Le 20 sept. 2020 à 14:02, Kaartic Sivaraam a écrit :\n> \n> On 20/09/20 3:14 pm, Luke Diamand wrote:\n>> On Sat, 19 Sep 2020 at 10:03, Luke Diamand wrote:\n>>> \n>>> Maybe this is a FAQ, but I couldn't figure it out!\n>>> \n>>> I have a repo which has a couple of submodules.\n>>> \n>>> At some point in the past I deleted one of those submodules:\n>>> \n>>> git rm sub2\n>>> git add -u\n>>> git commit -m 'Deleting sub2'\n>>> git push origin\n>>> ...\n>>> ... more commits and pushes...\n>>> \n>>> Now I go and clone the head revision. This gives me a clone which has\n>>> nothing present in .git/modules/sub2.\n>>> login on some other machine\n>>> git clone git@my.repo:thing\n>>> cd thing\n>>> ls .git/modules\n>>> \n>>> \n>>> So when I go and checkout an old revision where sub2 is still around I get:\n>>> git checkout oldrevision\n>>> fatal: not a git repository: sub2/../.git/modules/sub2\n>>> \n>>> What am I doing wrong?\n>>> What set of commands do I need to use to ensure that this will always\n>>> do the right thing?\n>>> \n>>> Thanks\n>>> Luke\n>> \n>> Replying to myself, adding Jens who added the section below.\n>> \n>> This is a known bug:\n>> \n>> https://git-scm.com/docs/git-rm\n>> \n>>> BUGS\n>>> ----\n>>> Each time a superproject update removes a populated submodule\n>>> (e.g. when switching between commits before and after the removal) a\n>>> stale submodule checkout will remain in the old location. Removing the\n>>> old directory is only safe when it uses a gitfile, as otherwise the\n>>> history of the submodule will be deleted too. This step will be\n>>> obsolete when recursive submodule update has been implemented.\n>> \n> \n> I don't think that part of the documentation applies to your case.\n\nI also don't think this part of the doc applies here. \n\n\n> So,\n> I also don't think this is a known bug. As a matter of fact, I couldn't\n> reproduce this with the following:\n> \n> \n> git init checkout-removed-submodule &&\n> cd checkout-removed-submodule/ &&\n> echo \"Hello, world\" >foo &&\n> git add foo && git commit -m \"Initial commit\" &&\n> git init ../submodule &&\n> cd ../submodule/ &&\n> echo \"Foo bar\" >foobar.txt &&\n> git add foobar.txt && git commit -m \"Foo bar baz\" &&\n> cd ../checkout-removed-submodule/ &&\n> git submodule add ../submodule/ foobar &&\n> git commit -m \"Add foobar submodule\" &&\n> git rm foobar/ &&\n> git commit -m \"Remove foobar submodule\" &&\n> git checkout HEAD~ # Checking out the \"Add foobar submodule\" commit\n\nYes. At this point \"foobar\" would be empty because '--recurse-submodules' was not used\non 'checkout'. Using `git checkout --recurse-submodules HEAD~` instead would populate it, \nand it would work correctly because the Git repository\nof foobar does exist at .git/modules/foobar.\n\n> I also tried with a cloned version of that repository as follows:\n\nhere let's make sure we re-checkout 'master' before cloning:\ngit checkout -\n\n> git clone /me/checkout-removed-submodule/ cloned-repo &&\n> cd cloned-repo &&\n> git co HEAD~\n> \n> I get:\n> \n> HEAD is now at 25270d8 Add foobar submodule\n\nI get the same thing, with or without '--recurse-submodules'.\n\nHowever, if I you have the 'submodule.active' \nconfiguration set to '.', which is the case if you *cloned* with '--recurse-submodules',\nand you then checkout with '--recurse-submodules',\nthen it fails as Luke describes:\n\ngit clone --recurse-submodules checkout-removed-submodule cloned-repo \ncd cloned-repo &&\ngit co --recurse-submodules HEAD~\n fatal: not a git repository: ../.git/modules/foobar\n fatal: could not reset submodule index\n\nThis bug was reported earlier in May [1], and I suggested a couple ways\nthe experience could be improved.\n\nI might add here that maybe a good idea would be that 'checkout'\nbe taught to try to clone the missing submodules if it does not find their \nrepository at .git/modules.\n\nCheers,\n\nPhilippe.\n\n[1] https://lore.kernel.org/git/20200501005432.h62dnpkx7feb7rto@glandium.org/T/#u\n\n"},{"id":"406107","messageId":"CAE5ih7-PsGpirnPVnCP__11qYBXeuP=tjQ9MC_d6oby-uqJy7A@mail.gmail.com","threadId":"54261","inReplyTo":"FFBB71FD-8D1F-4E86-9E37-813018AFC690@gmail.com","subject":"Re: How to checkout a revision that contains a deleted submodule?","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2020-09-22T04:32:56Z","receivedAt":"2020-09-22T04:33:12Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"On Tue, 22 Sep 2020 at 00:14, Philippe Blain\n wrote:\n>\n> Hi Luke and Kaartic,\n>\n> > Le 20 sept. 2020 à 14:02, Kaartic Sivaraam a écrit :\n> >\n> > On 20/09/20 3:14 pm, Luke Diamand wrote:\n> >> On Sat, 19 Sep 2020 at 10:03, Luke Diamand wrote:\n> >>>\n> >>> Maybe this is a FAQ, but I couldn't figure it out!\n> >>>\n> >>> I have a repo which has a couple of submodules.\n> >>>\n> >>> At some point in the past I deleted one of those submodules:\n> >>>\n> >>> git rm sub2\n> >>> git add -u\n> >>> git commit -m 'Deleting sub2'\n> >>> git push origin\n> >>> ...\n> >>> ... more commits and pushes...\n> >>>\n> >>> Now I go and clone the head revision. This gives me a clone which has\n> >>> nothing present in .git/modules/sub2.\n> >>> login on some other machine\n> >>> git clone git@my.repo:thing\n> >>> cd thing\n> >>> ls .git/modules\n> >>> \n> >>>\n> >>> So when I go and checkout an old revision where sub2 is still around I get:\n> >>> git checkout oldrevision\n> >>> fatal: not a git repository: sub2/../.git/modules/sub2\n> >>>\n> >>> What am I doing wrong?\n> >>> What set of commands do I need to use to ensure that this will always\n> >>> do the right thing?\n> >>>\n> >>> Thanks\n> >>> Luke\n> >>\n> >> Replying to myself, adding Jens who added the section below.\n> >>\n> >> This is a known bug:\n> >>\n> >> https://git-scm.com/docs/git-rm\n> >>\n> >>> BUGS\n> >>> ----\n> >>> Each time a superproject update removes a populated submodule\n> >>> (e.g. when switching between commits before and after the removal) a\n> >>> stale submodule checkout will remain in the old location. Removing the\n> >>> old directory is only safe when it uses a gitfile, as otherwise the\n> >>> history of the submodule will be deleted too. This step will be\n> >>> obsolete when recursive submodule update has been implemented.\n> >>\n> >\n> > I don't think that part of the documentation applies to your case.\n>\n> I also don't think this part of the doc applies here.\n>\n>\n> > So,\n> > I also don't think this is a known bug. As a matter of fact, I couldn't\n> > reproduce this with the following:\n> >\n> >\n> > git init checkout-removed-submodule &&\n> > cd checkout-removed-submodule/ &&\n> > echo \"Hello, world\" >foo &&\n> > git add foo && git commit -m \"Initial commit\" &&\n> > git init ../submodule &&\n> > cd ../submodule/ &&\n> > echo \"Foo bar\" >foobar.txt &&\n> > git add foobar.txt && git commit -m \"Foo bar baz\" &&\n> > cd ../checkout-removed-submodule/ &&\n> > git submodule add ../submodule/ foobar &&\n> > git commit -m \"Add foobar submodule\" &&\n> > git rm foobar/ &&\n> > git commit -m \"Remove foobar submodule\" &&\n> > git checkout HEAD~ # Checking out the \"Add foobar submodule\" commit\n>\n> Yes. At this point \"foobar\" would be empty because '--recurse-submodules' was not used\n> on 'checkout'. Using `git checkout --recurse-submodules HEAD~` instead would populate it,\n> and it would work correctly because the Git repository\n> of foobar does exist at .git/modules/foobar.\n>\n> > I also tried with a cloned version of that repository as follows:\n>\n> here let's make sure we re-checkout 'master' before cloning:\n> git checkout -\n>\n> > git clone /me/checkout-removed-submodule/ cloned-repo &&\n> > cd cloned-repo &&\n> > git co HEAD~\n> >\n> > I get:\n> >\n> > HEAD is now at 25270d8 Add foobar submodule\n>\n> I get the same thing, with or without '--recurse-submodules'.\n>\n> However, if I you have the 'submodule.active'\n> configuration set to '.', which is the case if you *cloned* with '--recurse-submodules',\n> and you then checkout with '--recurse-submodules',\n> then it fails as Luke describes:\n>\n> git clone --recurse-submodules checkout-removed-submodule cloned-repo\n> cd cloned-repo &&\n> git co --recurse-submodules HEAD~\n> fatal: not a git repository: ../.git/modules/foobar\n> fatal: could not reset submodule index\n>\n> This bug was reported earlier in May [1], and I suggested a couple ways\n> the experience could be improved.\n>\n> I might add here that maybe a good idea would be that 'checkout'\n> be taught to try to clone the missing submodules if it does not find their\n> repository at .git/modules.\n\nI was thinking this myself. I think the code change might be quite\nstraightforward.\n\nI added a test case for this problem here:\n\nhttps://lore.kernel.org/git/20200921081537.15300-2-luke@diamand.org/\n\nI think I could probably have a go at redoing this with an attempt at\na fix to get `git checkout` to clone missing submodules.\n\nLuke\n"}]}