Git-"<directory> 即使在删除该目录中的.git 之后，也没有签出提交。无法摆脱内部 git 回购</directory>

Question

Alright this is gonna be a bit confusing but please bear with me. Still getting used to git and Im struggling. So. The sequence of events were as follows (very hectic so ill summarise)

I have a project with backend and frontend. the frontend directory has a react app ( frontend/financee-app/ ) which by default has a .git initialised in it.

But my dumb self forgot to delete that inner repo before initialising a git repo for the whole project and committing and pushing my code.

So naturally, i couldnt open that react app folder on github cuz from what i learned till now is that its now a "submodule"? Which means theres a git repo within a git repo.

But after so many struggles and messing up my files, i replace my files with the backup files i had for this exact reason which have pretty much the same file structure as what i originally committed. BUT i made sure there is no inner git repo in the react app this time.

So i git pull my code to see what the differences are, it tells me theres three conflits. Two in two files. Which i fix, no problem. The third conflict is the freaking react app directory. Idk how to fix it so i just fix the other two, make sure i dont have a git repo in that app directory, and then i finally git add * .

Annnd. An error.

error: 'frontend/financee-app' does not have a commit checked out
fatal: updating files failed

Searching everywhere about that error, everyone keeps saying to delete the inner git repo. BUT I ALREADY DID. Is it detecting the one that i mistakenly pushed the first time that caused all these issues? What if i want to get rid of it for good. I just want to commit this new folder that doesnt have the git repo inside. I swear thats all i wanna do. Why is this so hard.

Answer 1

So naturally, i couldnt open that react app folder on github cuz from what i learned till now is that its now a "submodule"?

That's correct.

Which means theres a git repo within a git repo.

That's... not quite right. Git can't hold a repository inside a repository—or maybe won't is a better word here, as the reason is only partly technical—so a submodule is not a repository inside a repository, but rather a reference to some repository, inside a repository. That is, if we designate the outer Git repository as R (repo), and the inner one as S (submodule), what R contains is not S itself, but rather some directions or instructions: "Go find S and clone it. Then, check out commit C inside S ."

The directions/instructions are just a text file. They're stored in a file named .gitmodules ; when you clone R and use git submodule init , Git reads the file and tries to clone S per the instructions. If the instructions in .gitmodules are correct, that produces S . R does not contain S at all: R has just the instructions.

Having followed the instructions, the setup for, and commits within, repository R now have information recording the submodule-ness of S , and this is where things go wrong.

To stop R from thinking that S is a submodule, you must teach Git that it's not. There is a very large (and old, August 2009) StackOverflow question and answer all about this: How do I remove a submodule? The process used to be bad, but has been improved since 2009. See VonC's accepted answer .

 error: 'frontend/financee-app' does not have a commit checked out fatal: updating files failed

This is the symptom you will see when R still thinks that S exists as a submodule.