Hi Luke and Kaartic, > Le 20 sept. 2020 à 14:02, Kaartic Sivaraam <kaartic.sivaraam@xxxxxxxxx> a écrit : > > On 20/09/20 3:14 pm, Luke Diamand wrote: >> 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 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 [1], 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. [1] https://lore.kernel.org/git/20200501005432.h62dnpkx7feb7rto@xxxxxxxxxxxx/T/#u
