repository - 'git add .' doesn't work

Question

I am currently trying to setup Git for a project I have been working on for a while. I do remember quite a while ago setting up Git but never used it for various reasons. Now I want to use it i am getting a strange issue that I believe is related to an old install.

To start a fresh I installed a fresh Ubuntu OS so that there would be no Git install present and I copied the project (Grails) over. I then navigated to the directory and run the following commands:

git init

git remote add origin https://USERNAME@bitbucket.org/USERNAME/APPNAME.git

Then I ran:

git add .

This is where i get the error below:

fatal: Not a git repository: /home/user/workspace/App_V3/.git/modules/plugins/grails-spring-security-ui

This error is weird as this doesn't even match the directory I am in as the directory is below:

/home/user/Workspace/App_V7/

I am thinking that originally I may have setup the Git in the App_V3 folder on the old OS but don't know why it still points to that directory as I have run the code below to re-initialize it:

rm -rf .git
git init

Can someone please help me with this as its really frustrating :S

Thanks in advance

Answer 1

Moving repositories with submodules is problematic

I am thinking that originally I may have setup the Git in the App_V3 folder on the old OS

This is the source of the problem.

What matters is the version of git when the repository (or more specifically, the referenced submodule) was originally created.

Consider a repository with one submodule in vendor/awesome, how git behaved when creating the submodule is quite different.

git version < 1.7.8

The contents of vendor/awesome/.git is a folder - just like any git checkout so for example the folder structure of a checkout would be:

.gitmodules
.git
    ...
vendor/
    awesome
        .git
            config
            HEAD
            index
            packed-refs
            ...

There's no problem moving this kind of repository around, as there are no paths stored anywhere.

git version 1.7.8 or 1.7.9

1.7.8 moved the location of a submodule's .git folder

When populating a new submodule directory with "git submodule init", the $GIT_DIR metainformation directory for submodules is created inside $GIT_DIR/modules// directory of the superproject and referenced via the gitfile mechanism. This is to make it possible to switch between commits in the superproject that has and does not have the submodule in the tree without re-cloning.

Therefore vendor/awesome/.git is not a folder, it is a file with the following contents:

gitdir: /absolute/path/to/main/repo/.git/modules/vendor/awesome

And the overal folder structure is:

.gitmodules
.git
    ...
    modules
        vendor
            awesome
                config
                HEAD
                index
                packed-refs
                ...

vendor/
    awesome
        .git <- a file

The contents of .git/modules/vendor/awesome/config specifies where the working tree is:

[core]
   ...
   worktree = /absolute/path/to/main/repo/vendor/awesome

This was a pretty awesome change - however it introduced a problem, as absolute paths were used to reference locations.

git version >= 1.7.10

In version 1.7.10 the use of absolute paths in submodules was modified

The whole directory that houses a top-level superproject managed by "git submodule" can be moved to another place.

Now vendor/awesome/.git if generated with this or a later version of git would contain:

gitdir: ../../.git/modules/vendor/awesome

The contents of .git/modules/vendor/awesome/config specifies where the working tree is:

[core]
   ...
   worktree = ../../../../vendor/awesome

Once again, there's no problem moving this kind of repository around, as paths a relative to the main repository.

Moving repositories

With an old, or a new version of git - you're good.

If you're unfortunate enough to work on a repository created in 1.7.8 or 1.7.9 (which from the evidence in the question seems to be the case) and move the repository - there are 2 solutions:

1. Clone again
2. Correct paths in submodule .git files, and the corresponding worktree config setting