'git add .' doesn't work

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:

  • Having two different branches of one repo in two different locations on my local machine
  • Cleanup Strategies after Building Source Code using eg. Git
  • git and visual studio
  • Is it possible to 'fork a fork' in Github?
  • Can I squash _other peoples_ git commits in a submitted PR?
  • Gitlab-shell throwing 404 request for internal api requests?
  • 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

  • Remove a file from git which is not pushed yet but also not in latest commit?
  • Change Credentials for Push in Git
  • git show difference between commit messages
  • libgit2sharp remove remote branch
  • Deploy a Symfony website with Git on OVH shared server
  • Git - Difference between amend and squash commands
  • 3 Solutions collect form web for “'git add .' doesn't work”

    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

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

    Thanks for the help

    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.

    Git Baby is a git and github fan, let's start git clone.