This morning, right after I poured my coffee, colleague who sits across me asked an interesting question: What would happen if I initialize a #git repository one directory above existing repository?
I was actually confused. First of all, I was not sure why would he do that, and second, I was not sure what would happen. I did told him that he should make use of git submodules
but since I've never used them in practice, I could not explain to him how to use them. We did talk about this issue, but the conclusion was that we do not know enough.
So, adventurous as he is, my colleague wanted to test, with me right next to him viewing the result. To show you what we've done, I'll write down unix shell commands and file paths relative to home directory.
First, we created a directory inside a directory to look like this:git/folder1mkdir git && cd git && mkdir folder1
a new git repo was initialized with git init
. To simulate adding files to the repo, we created 3 empty files using touch
command:touch f1touch f2touch f3
command would show 3 files. Running git status
would show the same files as untracked
files with usual message to add them using git add
... You know the drill.
I'm skipping adding and committing these files and am moving back to git
directory using cd ..
command. Here, we initialized a new repository and did git status
immediately after. Directory we named folder1
was shown as untracked file. Nothing too suspicious as of yet.
Going back to folder1
, we made a commit on files created inside this folder and by using git status
we see the usual message nothing to commit
, meaning we committed everything. But, doing git status
directory laid a new message:modified: folder1 (modified content)
To be sure this isn't an "usual" message, we created another directory called folder2
in git directory and created a new file inside it called n1
. Doing git status
directory yielded this message:modified: folder1 (modified content)modified: folder3/n1
git could track files across directories, but not if one of those directories had another git already initialized. It seems that git inside git
works with encapsulations because most of the dangerous commands (such as git reset
) did nothing to the child git
"Very interesting" - we both concluded. Continuing on with our adventure, we initialized a new git repository inside folder2
. When running git status
in parent git
, we noticed that git initialization it self did not encapsulate the files inside folder2
, file n1
was still visible. Even after we added and committed the file in second git child
, git parent
still reported file n1
as modified (and tracked).
Basically, both parent git
and second child git
tracked the file. This incestuous relation had to end by simply removing folder2
from parent git
index.git rm --cached -r folder2
After committing the deletion we did above, now both directories showed the same message:modified: folder1 (modified content)modified: folder2 (modified content)
Both were again 'encapsulated'. Very interesting. I am still a bit clueless as to what was going on in here and have much to learn behind this, but damn if I wasn't impressed.