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?
Turns out, the common submodule configuration was inadvertently modified, and all references to this repo being a submodule were purged from .git/modules, .gitmodules, and .git/config.
I did a git rm -r common/ followed by a git submodule add, and all is now well.
Moral of the story: Messing around in the .git folder has the potential to cause weird things to happen.