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://[email protected]/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
This is because the node_modules folder is not ignored and hence when we run git add . command git visit all your directory/files and sub directory/files which is not ignored in . gitignore hence it is taking so long time to process it as node_modules contains a large amount of files and folder.
The folder which is giving you fatal: adding files failed message on git add command is actually implying that there is another . git folder inside the folder. If you navigate to the particular folder address, you can remove the file and put git add. It should work.
The git add command can be used to add ignored files with the -f (force) option. Please see git-commit[1] for alternative ways to add content to a commit.
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.
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.
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.
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.
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:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With