Note: This question references administration topics, but I figured stack overflow was more suited to a git question
I'm using git to manage a rather large stack of configuration files. Each relevant batch of files is separated off into a submodule, developed on a test server, and then pulled into the "master" branch which is used in the production server.
From my production server, I see:
$ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: common/manifests/file.pp # modified: updates (new commits) Here's the thing: common is a submodule just like updates. I'd expect to see the "new commits" wording here asking me to commit the submodule changes to the "main" repo.
If I drop down into the common directory, I see other changes, but most significantly, NOT the one that the upstream repository mentions.
$ cd common $ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: manifests/log.pp # no changes added to commit (use "git add" and/or "git commit -a") It seems like git is aware that the common folder is a separate repository only when I'm actually sitting in its working directory, but not when I'm in the upstream directory.
git --version comes back with 1.7.11.3
What's going on here, and how do I get git to start tracking the downstream directory as a submodule again?
