I have a folder containing a few Git repos that I cloned and made changes to, and I'm trying to add those repos to a private repo that I own, but this is what I get:

warning: adding embedded git repository: [my repository]
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> [my repository]

If I add the submodule at the URL where I originally cloned the repos from, I'd lose the changes I made (right?). So what URL do I enter so that my local copies of the cloned repos can be added to my new repo? Also, what would happen if I delete the .git files from those folders and just add them to my repo as regular folders? Would that achieve what I'm trying to do here?

CodePudding user response：

I have a folder containing a few Git repos that I cloned and made changes to...

If you made personal changes(changes different from the remote repository) to the submodules, there is no point of keeping them.

If you no longer want to get the changes from those remote repositories, the best option is to just delete the .git folder from those local repositories. Since your parent directory is also a git repository, it will keep the changes in those local repositories.

Another option is that you fork those remote repositories and add the URL of the forked repo as a submodule. Then you can push your own changes into your forks.

CodePudding user response：

A submodule is simply another Git repository.

If you choose to use submodules, you will have at least two Git repositories on your system (let's call it "your laptop" to make it clear where these are). One of your laptop repositories may have an origin of ssh://[email protected]/you/yourrepo.git, and the other—your submodule—may currently have an origin of ssh://[email protected]/them/theirrepo.git.

Commits you make, in your superproject (you/yourrepo.git clone), contain your files. They also contain a reference to a particular commit in your submodule: the other clone on your laptop. You must make commits in this clone.

For someone else who clones ssh://[email protected]/you/yourrepo.git to get these commits, they must clone a second Git repository. If you cannot push your commits to ssh://[email protected]/them/theirrepo.git, you'll need to set up some Git repository somewhere, where you can push your commits: e.g., ssh://[email protected]/you/theirrepo.git You'll then push the submodule commits here, so that others can retrieve this Git repository and its commits from here. You will change the URL for the laptop submodule to find its "source of truth" copy here, on GitHub.

Everyone now has two clones: their clone of ssh://[email protected]/you/yourrepo.git and, via git submodule update --init, their clone of ssh://[email protected]/you/theirrepo.git. So ssh://[email protected]/them/theirrepo.git is the URL you would list when creating the submodule in your clone of ssh://[email protected]/you/yourrepo.git.

It gets confusing, because there are so many Git repositories rolling around and being cloned left and right. Each clone has its own branch names and checkouts and so on. It will feel like instead of one simple thing,¹ a clone of a single master repository ssh://[email protected]/you/yourrepo.git, there are now dozens of complicated things flying around everywhere. And that's because there are.

This kind of thing is why many people avoid submodules. That, too, is an option. You can delete the repository that holds the submodule, keeping just the one checkout, and then git add those files to your repository. You then are back to the simple single repository case. You don't get the history from their repository, of course.

¹This assumes you find Git simple.