WORK IN PROGRESS
One of the problems developers new to git may face is
a mysterious sub-modules they didn't expect to have.
These are seen as a Submodule <pull request title> at <commit-hash>
under Files changed tab in a pull request.
You create your first repo following the instructions
from some tutorial when in your $HOME directory by
something like
mkdir programming
cd programming
git init
You learn and programming gets populated with files
and directories. Eventually it becomes bound with
a repo on GitHub and things goes quite well.
Next you create your second repo (by git init or
git clone) and decide that programming directory
is a good point to start at.
That's the problem. You have created a sub-module
for your programming repository. You won't face
any issues if you never introduce changes to programming
but once you do you will an unintended sub-module
(or a bunch of) in your programming repo.
Just move your projects so that they all have a common parent directory and neither is nested inside any another.
One day yuo decide to make some of your projects a part of a new project. So, you initialize a new repo and copy (or move) some old repo into it as a subdirectory.
The old one brought its own .git sub-directory along.
That's the problem. Any changes to the 'old' project
directory won't be tracked from the new parent project
and 'old' project will be treated as a sub-module.
Assuming you have already added, commited and pushed a submodule.
mv path/to/submodule path/to/submodule_tmpgit submodule deinit path/to/submodulegit rm path/to/submodulemv path/to/submodule_tmp path/to/submodulerm -rf path/to/submodule/.git
At this stage git status should expose files from your nested project
available as they were just created.
Now you are ready to git add, git commit and git push.