Question

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).

Answer 1

Does ../extern/Lib1 refer to a Git repository?
If it does not, Git wouldn’t know how to have 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.

---

"git submodule"^(man) code trusted the data coming from the config (and the in-tree .gitmodules file) too much without validating, leading to NULL dereference if the user mucks with a repository (e.g. when submodule.<name>.url is removed).
This has been corrected with Git 2.42 (Q3 2023).

See commit fbc806a (24 May 2023) by Taylor Blau (ttaylorr).
^{(Merged by Junio C Hamano — gitster — in commit 9cd234e, 20 Jun 2023)}

builtin/submodule--helper.c: handle missing submodule URLs

^{Reported-by: Tribo Dar
Signed-off-by: Taylor Blau}

In e0a862f ("submodule helper: convert relative URL to absolute URL if needed", 2018-10-16, Git v2.20.0-rc0 — merge listed in batch #9), prepare_to_clone_next_submodule() lost the ability to handle URL-less submodules, due to a change from:

if (repo_get_config_string_const(the_repostiory, sb.buf, &url))
    url = sub->url;

to

if (repo_get_config_string_const(the_repostiory, sb.buf, &url)) {
    if (starts_with_dot_slash(sub->url) ||
        starts_with_dot_dot_slash(sub->url)) {
            /* ... */
        }
}

,which will segfault when sub->url is NULL, since both starts_with_dot_slash() does not guard its arguments as non-NULL.

Guard the checks to both of the above functions by first checking whether sub->url is non-NULL.
There is no need to check whether sub itself is NULL, since we already perform this check earlier in prepare_to_clone_next_submodule().

By adding a NULL-ness check on sub->url, we’ll fall into the ‘else‘ branch, setting url to sub->url (which is NULL).
Before attempting to invoke git submodule--helper clone, check whether url is NULL, and die() if it is.