Sous-modules Git et accès ssh
J'ai quelques problèmes avec un dépôt git qui contient plusieurs sous-modules.
Le dépôt super git a été construit avec les commandes
mkdir projectname
cd projectname
git init
git submodule add ssh://myusername@server/pathtorepos
Lorsqu'un autre utilisateur ("autre utilisateur") clone ensuite le super référentiel, tout semble fonctionner. Mais quand il est temps d'avoir accès au sous-module
git submodule init
git submodule update
git tente de cloner le sous-module en utilisant "myusername" au lieu de "otheruser".
Comment résoudre ce problème?
Si possible, assurez-vous que le fichier .gitmodules contient une URL pour le référentiel qui peut être clonée par n'importe qui, généralement une URL git:// ou http://. Ensuite, les utilisateurs ayant eux-mêmes un accès SSH peuvent passer dans le sous-module après le clonage et modifier l'URL dans remote.Origin.url pour qu'il pointe vers une URL SSH avec leur nom d'utilisateur, par exemple:
cd my-submodule
git remote set-url Origin otheruser@server:/pathtorepos
L'autre utilisateur devrait pouvoir le faire même dans la situation actuelle. Mise à jour: / Chris Johnsen indique ci-dessous qu'il est également raisonnable d'utiliser une URL SSH dans .gitmodules si vous omettez le nom d'utilisateur et que tous les utilisateurs du référentiel auront un accès SSH - ils devront ajouter leur nom d'utilisateur de la même manière que le ci-dessus si elle diffère localement et à distance.
Notez que les URL dans .gitmodules ne sont utilisées que lors de initialisation du sous-module. L'initialisation du sous-module définit la valeur de configuration submodule.<SUBMODULE-NAME>.url dans le projet principal sur ce qui est engagé dans .gitmodules - il s'agit de la valeur qui sera utilisée lors de la première mise à jour du sous-module. Entre l’initialisation et la mise à jour du sous-module, vous pouvez également modifier cette URL qui sera utilisée pour cette première mise à jour avec une commande telle que:
git config submodule.my-submodule.url otheruser@server:/pathtorepos
En effet, vous devrez peut-être procéder ainsi si la première mise à jour échoue. Une fois que le sous-module a été mis à jour pour la première fois, l'URL que vous devez modifier est celle définie pour Origin dans le sous-module. À ce stade, il est utile de définir la valeur submodule.my-submodule.url config dans le projet principal si vous êtes susceptible de supprimer et réactualiser le sous-module.
L'autre utilisateur doit modifier le fichier .git/config pour modifier le nom d'utilisateur en son propre nom d'utilisateur. De cette façon, git utilise le bon utilisateur pour se connecter au serveur.
[submodule "path/to/module"]
url = ssh://otheruser@server/pathtorepos
Pour résoudre ce problème dans un projet open-source, nous entrons une URL RELATIVE dans le fichier .gitmodules. Cela entraînera git pour cloner l'URL du sous-module en fonction de l'URL en cours de clonage par le modèle d'URL du projet parent. L'utilisation d'un chemin relatif évite clairement de spécifier le protocole (https, ssh) et le nom d'utilisateur:
[submodule "my/tests/schemas"]
path = my/tests/schemas
url = ../my-schema
p.s. après avoir posté, je me suis rendu compte que ma réponse était une dupe, voici la source que vous devriez utiliser: Accéder automatiquement au sous-module via ssh ou https
Juste pour référence, la solution que j’ai finalement utilisée est la suivante… .. Il est en réalité possible pour d’autres de consulter le référentiel existant.
Lorsque je dois extraire le référentiel, cela peut être fait avec les commandes
git clone ssh://[email protected]/path/to/superrepos
cd superrepos
git submodule init
git submodule update
Pour que d'autres puissent accéder au super référentiel, le jeu de commandes suivant est utilisé ..__ La seule différence est le clonage manuel de l'autre référentiel
git clone ssh://[email protected]/path/to/superrepos
cd superrepos
git clone ssh://[email protected]/path/to/other/repos
git submodule init
git submodule update
Notez qu'après avoir émis le
git submodule init
lors de la commande, git vous dira que le référentiel demandé et disponible ne sont pas identiques. Mais ce n'est pas fatal et vous pouvez continuer en toute sécurité.
N'incluez pas le nom d'utilisateur dans l'URL. git demandera le nom d'utilisateur et le mot de passe lorsque vous clonez/tirez/etc