In my private repo on GitHub I found a submodule. This was unexpected. The GitHub project page showed the submodule as a folder with an arrow on it, but was not clickable.
This indicates that the submodule is ... incomplete at best, and at worst, quite broken.
Locally there was a folder of the submodule's name and in it a .git folder. Indicating that it had been git init locally.
Possibly—or perhaps you or someone ran git clone to create it. Either way, that .git directory (folder) contained the actual repository.
If there are other clones of that particular repository, those other clones exist, and have whatever state of up-to-date-ness that they have. If not, they do not exist.
Locally I renamed the .git folder in the submodule folder and ran from the parent git rm -f folder
That's all fine, except for one crucial piece of information. You renamed (or moved) this .git. Where did you put it?
Let's set up a similar situation. Note the long warning and hint sequence that Git prints here:
$ cd ~/tmp
$ mkdir tt
$ cd tt
$ git init
Initialized empty Git repository in .../tt/.git
$ mkdir sub
$ cd sub
$ git init
Initialized empty Git repository in .../tt/sub/.git
$ echo for testing > README
$ git add README
$ git commit -m initial
[master (root-commit) 1fd3599] initial
1 file changed, 1 insertion(+)
create mode 100644 README
$ cd ..
$ git add sub
warning: adding embedded git repository: sub
hint: You've added another git repository inside your current repository.
hint: Clones of the outer repository will not contain the contents of
hint: the embedded repository and will not know how to obtain it.
hint: If you meant to add a submodule, use:
hint:
hint: git submodule add <url> sub
hint:
hint: If you added this path by mistake, you can remove it from the
hint: index with:
hint:
hint: git rm --cached sub
hint:
hint: See "git help submodule" for more information.
What this has done is prepare my next commit with a gitlink.
A gitlink is the most important half of a submodule. The other half, which is also the most important, is the stuff that goes into a .gitmodules file: this is what tells the superproject Git (in tt/) how to clone the submodule tt/sub.
Since I made this submodule in a half-assed way, I have only half a submodule: the gitlink half. That's what the un-click-able folder icon on GitHub represents: a gitlink where the submodule cloning instructions are either missing entirely, or not present on GitHub. (If the submodule repository is on some other public access site, maybe they'd show more or allow clicking, but if it's totally private or missing, they can't show more; you can check the exact situation by looking at the .gitmodules file in the superproject.)
Now let me make my first commit in my superproject (in tt/), so that I actually refer to the submodule. Then I'll do what you did: move the .git folder somewhere, and run git rm -f sub:
$ git commit -m "initial in superproject"
[master (root-commit) 20ab8f6] initial in superproject
1 file changed, 1 insertion(+)
create mode 160000 sub
$ mv sub/.git save-the-repo
$ git rm -f sub
rm 'sub'
$ ls
save-the-repo
I have not yet committed, but once I do, I have a new commit where there is no gitlink. There is no half-assed submodule, nor a fully-assed submodule: there is nothing at all, because I never put anything else into the repository. Of course, the old commit still exists, and it still refers to the submodule:
git commit -m 'remove half-assed submodule'
[master b01e217] remove half-assed submodule
1 file changed, 1 deletion(-)
delete mode 160000 sub
Note the mode 160000, by the way: that's what Git uses to designate something as a gitlink. We can see it in the previous commit, and that it's gone in the current commit:
$ git ls-tree -r HEAD^
160000 commit 1fd3599ca076ba9f03c88661013810a9536921ea sub
$ git diff HEAD^ HEAD
diff --git a/sub b/sub
deleted file mode 160000
index 1fd3599..0000000
--- a/sub
+++ /dev/null
@@ -1 +0,0 @@
-Subproject commit 1fd3599ca076ba9f03c88661013810a9536921ea
Back to your problem
... thinking it would get rid of the submodule and just leave me with the real folder which I can then git add back into the repo
I must now repeat the question (already asked in a comment and here in this answer): Where did you put the original .git folder?
I put mine in save-the-repo. We see it above in the ls output. Your job is now to make some place to hold it and call it .git in that place:
$ mkdir recover
$ mv save-the-repo recover/.git
$ cd recover
$ git status
On branch master
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: README
no changes added to commit (use "git add" and/or "git commit -a")
To restore the files to their latest version, I can follow the advice above now, or more simply, git restore .:
$ git restore .
$ ls
README
$ git status
On branch master
nothing to commit, working tree clean
Note that this extracted the most recent commit on master. The .git repository here still exists, and still has all the commits in it that I made. I made only one commit of course, so that's all the commits. But if I now take the one README file and move it into sub, that's the only version I'll save back in the original repository:
$ cd ..
$ ls
recover
$ mkdir sub
$ mv recover/README sub/README
$ git add sub/README
$ git commit -m "move the latest sub/* files into the main repo, losing earlier ones"
[master 2af80e1] move the latest sub/* files into the main repo, losing earlier ones
1 file changed, 1 insertion(+)
create mode 100644 sub/README
$ git log --oneline
2af80e1 (HEAD -> master) move the latest sub/* files into the main repo, losing earlier ones
b01e217 remove half-assed submodule
20ab8f6 initial in superproject
I now have three commits: my first one, where I have the half-assed submodule, my second one where I removed it, and my third one where I created sub/ and populated it with the files (well, file, singular) from the latest commit in what used to be a submodule. The current version of the superproject does not depend on any submodules, but older commits in the superproject do—and since there's no .gitmodules giving instructions for where to clone the submodule, those half-assed submodules are broken.
Truly fixing this, leaving no trace of a mistake, would involve creating new history from scratch, where either the submodule is added correctly at the start, or never created as a gitlink in the first place. Then, for every superproject and/or submodule commit, I'd make another new commit to update all the files in the new combined project. But this is just a demo.
