'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. No

Answer 1

I moved all of the files one at a time to a new folder and then seemed to work fine :)

Thanks for the help

Answer 2

Instead of

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

you should use

git clone origin https://USERNAME@bitbucket.org/USERNAME/APPNAME.git .

since you want to clone an existing repository and not re-create it.

Answer 3

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