From other answers like here I learned that this results in a nested repository. How exactly does that look? Can one switch between them How does it work when they both have the same name?
I did this by mistake and it rather looks as if the original one was overwritten. The .gitignore is replaced and I see only the branches of the new repository while the files of the old one are shown in the working directory.
CodePudding user response:
The git clone
command refuses to run in an occupied directory.
The default git clone
operation:
git clone <url>
creates a new, empty directory so that the new clone isn't using an occupied directory. You can, however, write:
git clone <url> <path>
to tell git clone
to use the specified path
. In this case, path
must name an existing, empty directory or be able to be created as an empty directory. The empty directory will be filled by git clone
. If the path
argument names a directory that exists and is not empty, git clone
refuses to run.
"Nested" repositories occur when the working tree of a normal, everyday repository contains a directory that is itself the working tree of another Git repository.
For instance, suppose you ran:
git clone https://github.com/git/git.git
to create ./git
as the working tree of a clone of the Git repository for Git, then:
cd git
to enter this working tree. Inspecting the tree with "show hidden files" (e.g., ls -A
on a Linux system), you'd see that there is a .git
directory here. This hidden .git
directory contains the actual repository; the top level git
that you did a cd git
to get into holds the working tree.
If you now ran:
git clone <other-url> project
and created a new directory project
within the working tree, running ls -A project
or similar would show you that project
, too, contains a .git
directory. The project
directory is the working tree of this other repository.
Running git add project
now (which will print a gigantic warning message), and then running git commit
, would add a gitlink to the Git repository for Git. The gitlink is half of a submodule. The half that's missing at this point is the .gitmodules
file, which git submodule add
would have created, but running git add project
didn't. This is a fundamental mistake: the commit created at this point has what I like to call a "half-assed submodule" that cannot be used sensibly. That's why git add project
prints that gigantic warning message. (It would probably be better if git add project
refused to add it at all, really, but that would not be backwards-compatible, and the Git folks are very big on being backwards-compatible for decades at a time.)
Whatever your actual problem is, then, it's something you have not described properly here.