Why is it a bad idea to git init in a subfolder of a folder in which I have already run git init

Question

on softwarecarpentry they say that it is a bad idea to enter the following command sequence:

cd             # return to home directory
mkdir planets  # make a new directory planets
cd planets     # go into planets
git init       # make the planets directory a Git repository
mkdir moons    # make a sub-directory planets/moons
cd moons       # go into planets/moons
git init       # make the moons sub-directory a Git

Why is it a bad idea.

*"Why is it a bad idea to do this?"* - you are supposed to be figuring it out. Why not try it and find out? Side note: if you want a repo in another repo, look up *"git submodules"* — jonrsharpe, May 14 '16 at 07:55

score 1 · Accepted Answer · edited May 23 '17 at 12:01

Because you would create a git nested repo, which

will be recorded by the parent repo as a gitlink (special entry in the index)
but whose content would be otherwise ignored

As opposed to a submodule (which also records a gitlink, and the submodule url in the parent .gitmodules file), a repo with a nested git repo in it would not be able to get the nested repo content back: all the parent has is a SHA1 in the entries of its index. It does not have the url of the nested repos.
Anybody cloning the parent repo would get an "empty folder" for the nested git repo, without being able to find to which other repo this "empty folder" is for.
You can see a concrete example of such a folder in "Visual Studio 2015 Community: Commit to GitHub via command line produces inaccessible file…?"

Why is it a bad idea to git init in a subfolder of a folder in which I have already run git init

1 Answers1