Impossible d'ajouter un sous-module git lorsqu'il est spécifié comme chemin relatif

Question

J'essaie d'ajouter un sous-module à mon dépôt git, et j'obtiens cette erreur en retour :

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

des idées sur ce que cela pourrait être ?J'ai essayé de chercher sur Google, mais un seul lien vague apparaît.

Je fais ça:

git submodule add ../extern/Lib1 lib  

Je m'attends à ce que cela crée un sous-module lib/Lib1
Je suis conscient que cela ne fera que créer une référence et que je devrai ensuite mettre à jour/init (pas très clair sur cette partie, je ne suis pas allé aussi loin ;J'apprends juste la commande du sous-module).

Answer 1

Fait ../extern/Lib1 faire référence à un dépôt Git ?
Si ce n'est pas le cas, Git ne saura pas comment placer l'URL du dépôt Git sur son site. .gitmodule
Essayez aussi:

• avec la destination lib pas déjà existant (même vide)
• avec un chemin absolu au lieu d'un chemin relatif (vous pouvez en utiliser un relatif, mais juste au cas où, cela vaut la peine d'essayer ici)

Voici quelques bonnes sources sur les sous-modules :

• chapitre 8 du manuel de l'utilisateur de Git
• Page wiki sur le didacticiel du sous-module Git
  et bien sûr
• Page de manuel du sous-module Git

---

Puisque seul le chemin absolu fonctionne ici, cela signifie que le chemin relatif nécessite une référence à comparer.
Cette référence est "l'origine distante" qui devrait être dans votre DirName/NewRepo_withSubmodules/.git/config fichier, comme ceci :

$ cat .git/config
    ...
    [remote "origin"]
    url = /path/to/DirName/NewRepo_withSubmodules/.git
    fetch = +refs/heads/*:refs/remotes/origin/*
    ...

Si vous avez cette section dans ../DirName/NewRepo_withSubmodules/.git/config fichier, vous devriez pouvoir ajouter ../Extern/Lib1 en tant que sous-module utilisant un chemin relatif.

Tout ce qui précède est inspiré de la section suivante de la page de manuel du sous-module git :

<repository> est l'URL du référentiel d'origine du nouveau sous-module.
Il peut s'agir soit d'une URL absolue, soit (si elle commence par ./ ou ../), l'emplacement par rapport au superprojet origin dépôt.

Donc si NewRepo_withSubmodules est un dépôt Git local qui vient d'être créé (et n'a bien sûr pas d'"origine"), une "origine distante" artificielle doit être définie (même si l'origine pointe vers elle-même), ne serait-ce que pour permettre une URL relative pour un autre sous-module référentiels à utiliser.

---

Git 2.13 (Q2 2017) améliorera la détection de l'origine par défaut d'un sous-module.

Voir commettre d1b3b81 (25 février 2017) par Stéphane Beller (stefanbeller).
^{(Fusionné par Junio ​​C Hamano-- gitster -- dans commettre ae900eb, 10 mars 2017)}

submodule init:avertir du retour à un chemin local

Comme maintenant documenté:

<repository> est l'URL du référentiel d'origine du nouveau sous-module.
Il peut s'agir soit d'une URL absolue, soit (si elle commence par ./ ou ../), l'emplacement par rapport au référentiel distant par défaut du superprojet
(Veuillez noter que pour spécifier un référentiel 'foo.git' qui est situé juste à côté d'un superprojet 'bar.git', vous devrez utiliser '../foo.git' au lieu de './foo.git' - comme on pouvait s'y attendre en suivant les règles relatives aux URL relatives - car l'évaluation des URL relatives dans Git est identique à celle des répertoires relatifs).

La télécommande par défaut est la télécommande de la branche de suivi à distance de la branche actuelle.
Si aucune branche de suivi à distance n'existe ou si le HEAD est détaché, "origin" est supposé être la télécommande par défaut.
Si le superprojet n'a pas de télécommande par défaut configurée, le superprojet fait autorité en amont et en cours.le répertoire de travail est utilisé à la place.

---

Git 2.20 (T4 2018) améliore la prise en charge du chemin local pour les sous-modules.

Voir commettre e0a862f (16 octobre 2018) par Stéphane Beller (stefanbeller).
^{(Fusionné par Junio ​​C Hamano-- gitster -- dans commettre 3fc8522, 06 novembre 2018)}

submodule helper:convertir l'URL relative en URL absolue si nécessaire

L'assistant du sous-module update_clone appelé par "git submodule update", Clones sous-modules si nécessaire.
Comme les sous-modules avaient l'URL indiquant s'ils étaient actifs, l'étape de résolution des URL relatives était effectuée dans le "submodule init" étape.De nos jours, les sous-modules peuvent être configurés actifs sans appeler un init explicite, par ex.via la configuration submodule.active.

Lorsque vous essayez d'obtenir des sous-modules qui sont définis actifs de cette façon, nous allons se replier sur l'URL trouvée dans le .gitmodules, qui peut être relatif au superproject, mais nous ne le résolvons pas encore:

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
[...]

Pour résoudre le problème, facteurs de la fonction qui résout les URL relatives "dans"git submodule init" (dans le sous-module helper du init_submodule fonction) et appelez-le à l’endroit approprié dans le update_clone assistant.

Answer 2

Je tentais la même chose, et a trouvé ce qui suit « semble avoir travaillé:

J'ai (sur Windows):

D:/phd/analyses
    /analysis1/ #This is an existing repository
    /analysis2/ #another existing repository
    /analysis3.tex
    /analysis4.tex
    ...
    /analysisN.tex

analysis1.tex ... analysisN.tex contiennent des idées que je ne l'ai pas encore travaillé sur ( 'talons, par exemple), et analysis1/ et analysis2/ sont des choses que je travaille sur (et donc avoir le code, tex, ... en eux). Une fois que je me déplace à travailler sur les autres analyses, ils seront déplacés vers leurs propres dossiers et donc leurs propres référentiels.

Ce que je faisais était (en bash git dans les 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"

Cela semble avoir fonctionné.

D:/phd/analyses/.git/config semble comme il se doit, et .gitmodules ressemble à:

[submodule "analysis2"]
    path = analysis2
    url = self:analysis2/.git
[submodule "analysis5"]
    path = analysis5
    url = self:analysis5/.git

Cordialement, Simon Knapp

Answer 3

(je résumez simplement la solution ici. Le crédit va à VonC.)

Dans le référentiel contenant (par exemple de containing.git/), git interprète comme des chemins relatifs par rapport à la distance de origin, qui ne sont pas définis. Nous voulons que ce soit par rapport au répertoire containing.git/, donc exécuter

git remote add origin ..

(Je ne sais pas pourquoi il est .. plutôt que ..)

Maintenant, vous pouvez ajouter le sous-module:

git submodule add ../extern/Lib1 lib