I had a similar issue, but had painted myself into a corner with GUI tools.
I had a subproject with a few files in it that I had so far just copied around instead of checking into their own git repo. I created a repo in the subfolder, was able to commit, push, etc just fine. But in the parent repo the subfolder wasn't treated as a submodule, and its files were still being tracked by the parent repo - no good.
To get out of this mess I had to tell Git to stop tracking the subfolder (without deleting the files):
proj> git rm -r --cached ./ui/jslib
Then I had to tell it there was a submodule there (which you can't do if anything there is currently being tracked by git):
proj> git submodule add ./ui/jslib
The ideal way to handle this involves a couple more steps. Ideally, the existing repo is moved out to its own directory, free of any parent git modules, committed and pushed, and then added as a submodule like:
proj> git submodule add [email protected]:user/jslib.git ui/jslib
That will clone the git repo in as a submodule - which involves the standard cloning steps, but also several other more obscure config steps that git takes on your behalf to get that submodule to work. The most important difference is that it places a simple .git file there, instead of a .git directory, which contains a path reference to where the real git dir lives - generally at parent project root .git/modules/jslib.
If you don't do things this way they'll work fine for you, but as soon as you commit and push the parent, and another dev goes to pull that parent, you just made their life a lot harder. It will be very difficult for them to replicate the structure you have on your machine so long as you have a full .git dir in a subfolder of a dir that contains its own .git dir.
So, move, push, git add submodule, is the cleanest option.