Asked  7 Months ago    Answers:  5   Viewed   58 times

I created a GitHub repository and made a .gitmodules file directly from GitHub's web source editor. When I then cloned the repo, I noticed the submodules in .gitmodules were not being initialized.

I think I tried almost all commands possible, including update, init, update --init and so on. Is there a way to use current .gitmodules file, not submodules add?



Writing a submodule isn't enough.

You should rather use git submodule add: that will update your .gitmodules file and create a special entry in the index (where you want that submodule to be loaded).

Then, when you push that to your upstream repo on GitHub, the project page will display those special entries as a green folder.

green folder

Tuesday, June 1, 2021
answered 7 Months ago

You can use git submodules to "link" to other projects. See here -

Tuesday, July 27, 2021
answered 5 Months ago
git checkout gh-pages
git merge master
git push origin gh-pages
Saturday, July 31, 2021
answered 4 Months ago

Let's say we have a file that was inadvertently added to our repository:

stackoverflow$ echo this file is important > junkfile
stackoverflow$ git add junkfile
stackoverflow$ git ci -m 'added a file'

At some point, we realize that the file is unimportant so we add it to our .gitignore file:

stackoverflow$ echo junkfile >> .gitignore
stackoverflow$ git ci -m 'ignore junkfile' .gitignore

Later on, we make some changes to that file:

stackoverflow$ sed -i 's/ is / is not/' junkfile 

And of course, even though the file is listed in .gitignore, we have already told git that we want to track it, so git status shows:

stackoverflow$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#   modified:   junkfile
no changes added to commit (use "git add" and/or "git commit -a")

We need to remove this file from the repository (without removing the file from our work tree). We can do this with the --cached flag to git rm:

stackoverflow$ git rm --cached junkfile
rm 'junkfile'

This stages the delete operation...

stackoverflow$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#   deleted:    junkfile
# we need to commit it:

stackoverflow$ git commit -m 'removed junkfile from repository'
[master 19f082a] removed junkfile from repository
 1 file changed, 1 deletion(-)
 delete mode 100644 junkfile

Now if we run git status git will ignore this file:

stackoverflow$ git status
# On branch master
nothing to commit, working directory clean

Even though it's still here in our working tree:

stackoverflow$ cat junkfile 
this file is not important
Friday, September 3, 2021
answered 3 Months ago

What you have here is a broken submodule. (Or half a submodule? A submodule without instructions? It's not clear just what to call it—other than, as VonC notes, we can say that the gitlink half is a "gitlink", which at least is a searchable jargon term.)

A submodule, in Git, is a reference to another Git repository. In order to use the submodule, you must already have the other Git repository. In general, to make a Git repository, we mostly use git clone to copy some other, existing, repository. So normally, a submodule carries along with it the necessary instructions that Git will need in order to run git clone. These instructions go into the .gitmodules file.

If the .gitmodules file is missing, as in this case, it means that the instructions for setting up the submodule are missing. It's up to you whether to repair this by adding the instructions, or to repair it by removing the badly-formed submodule from your next commit.

Removing the half-formed submodule is easier. See VonC's accepted answer to No submodule mapping found in .gitmodule for a path that's not a submodule, but all you have to do is use git rm and then commit. This new commit will no longer refer to the submodule that cannot be cloned because the cloning instructions are missing. Subsequent new commits, built from this commit that doesn't mention the submodule, also won't mention the submodule (which continues to not exist).

Note that all existing commits remain broken. The only thing you can do about this is to remove (or replace) any existing broken commits, because no existing commit can be modified. It's generally not a great idea to try to fix or remove existing commits, as other people may be depending on them. A half-submodule / broken-submodule like this can be worked-with as a regular (non-broken) submodule if you have the other Git repository cloned into place.

To fix the problem by fixing the submodule, put the appropriate configuration into a new .gitmodules file and git add and git commit the .gitmodules file. The problem with actually doing this, of course, is that you need to know what the instructions are. Some of them are clear from the broken submodule, because the information in the .gitmodules file comes in several parts: one part is the path, which is just the name of the mode-160000 git ls-files entry (again, see VonC's answer). But the other part is the URL for the repository that should be cloned, and who knows what that might be?1

1In theory, whoever owns whichever repository you cloned to get into this situation should know—or, they should know who knows, or know someone who knows someone who knows, etc. But in practice, you get a lot of It was like that when I got here.

Wednesday, December 1, 2021
answered 3 Days ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :