Re: How to checkout a revision that contains a deleted submodule?

From: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Date: Sep 20, 2020, 18:02 UTC
Message-ID: <4eb688f2-0c17-9b85-e60e-f07485895622@gmail.com>
In-Reply-To: <CAE5ih79puooMA1v8jOkqKaO9xPmYqtkT9kXHq2L6YODJJ8oGEQ@mail.gmail.com>

On 20/09/20 3:14 pm, Luke Diamand wrote:

Show 49 quoted lines

> On Sat, 19 Sep 2020 at 10:03, Luke Diamand <luke@diamand.org> 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@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
> 
>> 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. 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

I get:

 HEAD is now at 25270d8 Add foobar submodule

I also tried with a cloned version of that repository as follows:
 git clone /me/checkout-removed-submodule/ cloned-repo &&
 cd cloned-repo &&
 git co HEAD~

I get:

 HEAD is now at 25270d8 Add foobar submodule

So, I don't get any errors when I checkout a revision where the deleted submodule is still around. There might other factors in play such as,

- the version of Git being used
- whether `--recurse-submodules` was passed to checkout
- the configuration of the submodule in .gitmodules

It would be great if you could share these and possibly other useful information to help us identify why you get an error when checking out the revision.

-- Sivaraam