Home > other >  What happens to a git repository when cloning another one into the same folder?
What happens to a git repository when cloning another one into the same folder?

Time:10-17

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.

  •  Tags:  
  • git
  • Related