In my main parent repo, I added a submodule normally and committed. I then made a handful of commits to my project unrelated to that submodule.
After those commits, I decided I needed to change my associated email for commits, so I updated my global git config's user.email, then cd'd into my submodule ran git rebase -r --root --exec "git commit --amend --no-edit --reset-author" and pushed. to retroactively change the email throughout the git history. Then I cdd back into my parent repo ../ and pulled the new submodule version with git submodule update --remote containing the correct email. I committed this, so the latest version of parent contains the latest version of submodule.
However, it looks like retroactively changing my email throughout the submodules' commit history has regenerated all of the commit hashes. The submodule's hash is now abc123, while before it was xyz456. When I go to my parent repo on github, I can see at the most recent commit has
my_submodule @ abc123
which correctly brings me to my submodules git repo on github on click.
But every previous commit in parent shows
my_submodule @ xyz456
and when I click on that submodule reference, I see the warning
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This means that if you checkout a previous commit of parent, where my_submodule still points to xyz345, you can see my old email address with git log inside of the submodule, which I want to prevent.
I need to retroactively replace all references of my_submodule throughout every past commit (after it was added to the repository) with this new reference at commit abc123.
Can I use git-filter for this, like people do to retroactively remove a sensitive file throughout all commits?
I want a solution that will look as if my_submodule were always pointing to abc123, with no extra commits up to this point.