Wsrtjtyk

I'm trying to add a submodule to my git repo, and I'm getting this error in return:

remote origin does not have a url defined in .git/config

any ideas about what this might be? I tried googling for it but only one vague link comes up.

I'm doing this:

git submodule add ../extern/Lib1 lib  

I'm expecting this to create a submodule lib/Lib1

I'm aware that this will only create a reference and that I then have to update/init (not crystal clear on this part, haven't gotten that far; I'm just learning the submodule command).

Does ../extern/Lib1 refer to a Git repository?

If it does not, Git wouldn't know how to had the Git repo url to its .gitmodule

Also, try:

• with the destination lib not already existing (even empty)


• with an absolute path instead of a relative path (you can use a relative one, but just in case, it is worth a try here)

Some good sources on submodules are:

• chapter 8 of Git User's manual


• 
  Wiki page on Git Submodule Tutorial
  
  and of course


• Git submodule man page

Since only the absolute path works here, it means the relative path need a reference to be compared against.

That reference is the "remote origin" which should be in your DirName/NewRepo_withSubmodules/.git/config file, like so:

$ cat .git/config

    ...

    [remote "origin"]

    url = /path/to/DirName/NewRepo_withSubmodules/.git

    fetch = +refs/heads/*:refs/remotes/origin/*

    ...

If you do have that section in ../DirName/NewRepo_withSubmodules/.git/config file, you should be able to add ../Extern/Lib1 as a submodule using a relative path.

All the above is inspired from the following section of the git submodule man page:

<repository> is the URL of the new submodule's origin repository.

This may be either an absolute URL, or (if it begins with ./ or ../), the location relative to the superproject's origin repository.

So if NewRepo_withSubmodules is a local Git repo which has just been created (and has of course no "origin"), an artificial "remote origin" ought to be defined (even if the origin points to itself), if only to allow relative url for other submodule repositories to be used.

Git 2.13 (Q2 2017) will improve the detection of the default origin of a submodule.

See commit d1b3b81 (25 Feb 2017) by Stefan Beller (stefanbeller).
^{(Merged by Junio C Hamano -- gitster -- in commit ae900eb, 10 Mar 2017)}

submodule init: warn about falling back to a local path

As now documented:

<repository> is the URL of the new submodule's origin repository.

This may be either an absolute URL, or (if it begins with ./ or ../), the location relative to the superproject's default remote repository

(Please note that to specify a repository 'foo.git' which is located right next to a superproject 'bar.git', you'll have to use '../foo.git' instead of './foo.git' - as one might expect when following the rules for relative URLs - because the evaluation of relative URLs in Git is identical to that of relative directories).

The default remote is the remote of the remote tracking branch of the current branch.

If no such remote tracking branch exists or the HEAD is detached, "origin" is assumed to be the default remote.

If the superproject doesn't have a default remote configured the superproject is its own authoritative upstream and the current.
working directory is used instead.

Git 2.20 (Q4 2018) improves local path support for submodules.

See commit e0a862f (16 Oct 2018) by Stefan Beller (stefanbeller).
^{(Merged by Junio C Hamano -- gitster -- in commit 3fc8522, 06 Nov 2018)}

submodule helper: convert relative URL to absolute URL if needed

The submodule helper update_clone called by "git submodule update",
clones submodules if needed.

As submodules used to have the URL indicating if they were active, the step to resolve relative URLs was done in the "submodule init" step. Nowadays submodules can be configured active without calling an explicit init, e.g. via configuring submodule.active.

When trying to obtain submodules that are set active this way, we'll
fallback to the URL found in the .gitmodules, which may be relative to the
superproject, but we do not resolve it, yet:

git clone https://gerrit.googlesource.com/gerrit

cd gerrit && grep url .gitmodules

url = ../plugins/codemirror-editor

...

git config submodule.active .

git submodule update

fatal: repository '../plugins/codemirror-editor' does not exist

fatal: clone of '../plugins/codemirror-editor' into submodule path '/tmp/gerrit/plugins/codemirror-editor' failed

Failed to clone 'plugins/codemirror-editor'. Retry scheduled

[...]

fatal: clone of '../plugins/codemirror-editor' into submodule path '/tmp/gerrit/plugins/codemirror-editor' failed

Failed to clone 'plugins/codemirror-editor' a second time, aborting

[...]

To resolve the issue, factor out the function that resolves the relative
URLs in "git submodule init" (in the submodule helper in the init_submodule function) and call it at the appropriate place in the update_clone helper.

I was trying the same thing, and found the following 'seems to have worked:

I have (on windows):

D:/phd/analyses

    /analysis1/ #This is an existing repository

    /analysis2/ #another existing repository

    /analysis3.tex

    /analysis4.tex

    ...

    /analysisN.tex

analysis1.tex ... analysisN.tex contain ideas I've not worked on yet ('stubs, say), and analysis1/ and analysis2/ are things I am working on (and hence have code, tex, ... in them). Once I get around to working on the other analyses, they will get moved to their own folders and hence their own repositories.

What I did was (in git bash in analyses):

git init

git add *.tex

git remote add self .

git submodule add self:/analysis2/.git analysis2

git submodule add self:/analysis5/.git analysis5

git commit -m "Initial commit"

This seems to have worked.

D:/phd/analyses/.git/config looks like it should, and .gitmodules looks like:

[submodule "analysis2"]

    path = analysis2

    url = self:analysis2/.git

[submodule "analysis5"]

    path = analysis5

    url = self:analysis5/.git

Regards,
Simon Knapp

(I've summarized just the solution here. Credit goes to VonC.)

In the containing repository (say containing.git/), git interprets relative paths as relative to the origin remote, which is not defined. We want it to be relative to the containing.git/ directory, so run

git remote add origin ..

(Not sure why it's .. rather than ..)

Now you can add the sub-module:

git submodule add ../extern/Lib1 lib