3

On a fresh git repo, after adding a submodule and changing to the submodule directory most git commands fail when run within the submodule with the error:

fatal: index file open failed: Not a directory

The full set of commands to reproduce the issue:

>  git init .
Initialized empty Git repository in /Users/drh/code/personal/Experiments/git-test/.git/
>  git status
On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)
>  git submodule add git@github.com:mitsuhiko/flask.git thirdparty/flask
Cloning into 'thirdparty/flask'...
remote: Reusing existing pack: 9959, done.
remote: Total 9959 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (9959/9959), 5.17 MiB | 1.11 MiB/s, done.
Resolving deltas: 100% (5617/5617), done.
Checking connectivity... done.
>  cd thirdparty/flask
>  git status
fatal: index file open failed: Not a directory
>  cat .git
gitdir: ../../.git/modules/thirdparty/flask

git version 1.8.5.2 running on Mavericks

danielrhammond
  • 43
  • 4
  • Just to experiment ... I tried symlinking .git to the correct directory (../../.git/modules/thirdparty/flask) which resolves the immediate problem of the index file open failing, but it seems to mess with how git detects the dirty state of the submodule and probably has other negative side-effects – danielrhammond Jan 11 '14 at 04:01
  • Solved this. To close the loop for anyone else this was fixed by opening a new terminal session. I suspect it was some sort of weird state with some git environment variables (maybe GIT_DIR). – danielrhammond Jan 11 '14 at 04:31

2 Answers2

3

I personally was seeing this problem in my pre-commit hooks for some submodule automation. Environment variables GIT_DIR, GIT_WORK_TREE, GIT_INDEX_FILE, etc.. were causing the issue. I was able to fix this problem with env -i git <git-command>, which is a simple way to use a clean bash enviornment with a single command.

Davey
  • 156
  • 4
0

That is because there isn't a commit yet in the parent repo (meaning no HEAD, and no master branch).
As you have detected, the GIT_DIR for the parent repo might be set too late for the submodule to use.
That would be a good bug to report if none of the git submodule tests cover that scenario.

Or, as the OP user3184153 commented:

I think that some other application (I suspecting virtualenv, though can't reproduce) was setting GIT_DIR.

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • Hmmm thanks for the assist, though I just tried this with a new repo and it did work even with no commit in the parent repo. I think that some other application (I suspecting virtualenv, though cant reproduce) was setting GIT_DIR – danielrhammond Jan 15 '14 at 19:42
  • @user3184153 Ok. I have included your conclusion in the answer for more visibility. – VonC Jan 15 '14 at 20:10