2010-07-27 11 views
7

J'ai besoin de quelque chose qui s'apparente à des sous-modules, mais qui existent en dehors du référentiel principal en tant que dépendance.Comment ajouter un dépôt git en tant que dépendance partagée d'un autre dépôt git?

Voici le problème:

Je suis en train d'utiliser Git (d'une manière très maladroite) pour gérer les fichiers de conception d'un outil de CAO (Cadsoft Aigle), et je vais avoir du mal à comprendre out s'il existe un moyen d'utiliser les sous-modules git pour gérer la dépendance de chaque projet par rapport à la bibliothèque partagée de l'outil de CAO.

J'utilise une structure de dossiers comme celui-ci:

~/eagle/ <-- Main library used by multiple projects 
    .git/  
    <library files> 

~/projects/ <-- Projects folder 
    Proj0/ 
     .git/ 
     <design files> 
    Proj1/ 
     .git/ 
     <design files> 

Dans ce cas, il n'a pas de sens pour ajouter le référentiel eagle.git comme un sous-module git pour chaque projet.

Cependant, j'ai encore besoin d'un moyen de prendre un instantané de l'état actuel du référentiel "eagle.git" de sorte que si la bibliothèque est mise à jour, elle peut être restaurée pour accéder à la révision spécifique des fichiers de bibliothèque étaient utilisés lorsque le Proj [x] était engagé.

Idéalement, je voudrais quelque chose comme ce qui suit:

~/eagle/ <-- Main library used by multiple projects 
    .git/  
    <library files> 

~/projects/ <-- Projects folder 
    Proj0/ 
     .git/ 
     <design files> 
     **eagle** <-- something that acts like a submodule 
         but which actually points to ~/eagle/ 
    Proj1/ 
     .git/ 
     <design files> 
     **eagle** <-- something that acts like a submodule 
         but which actually points to ~/eagle/ 

Je voudrais pouvoir:

cd ~/projects/Proj0 
git submodule update 

et ont le ~/aigle/répertoire rouler automatiquement à la révision vérifiée dans Proj0.

Quelqu'un sait quoi que ce soit dans Git qui pourrait permettre ce genre de comportement?

+0

Pouvez-vous expliquer pourquoi les sous-modules ne fonctionneront pas pour vous ici? Il me semble que les sous-modules sont exactement ce dont vous avez besoin. –

+0

Pour que l'outil de CAO (Eagle) puisse "voir" une bibliothèque, il doit être ajouté aux paramètres de chemin d'accès de Eagle. Si j'ajoutais le dépôt de la bibliothèque "aigle" comme sous-module pour chaque projet, je devais ajouter manuellement les paramètres de chemin d'accès du chemin de la bibliothèque du sous-module de chaque projet, ce qui ferait apparaître [x] copies de la bibliothèque "aigle" dans Eagle gestionnaire de bibliothèque. Déterminer ce qu'il faut faire et gérer ces copies séparées dans l'outil de CAO serait un cauchemar. En outre, la bibliothèque peut avoir des ordres de grandeur plus grands que les fichiers du projet, il semble donc vraiment inutile d'en avoir [x] copies sur le disque. – cdwilson

+0

Une manière utile de penser à ceci est par l'intermédiaire d'une analogie. Disons que l'outil DAO Eagle est une usine qui peut fabriquer un widget à la fois. Disons que chaque projet [x] .git repo est représenté par un plan de fabrication [x] pour un widget [x] fabriqué par l'usine. Le repo eagle.git est représenté par la configuration d'usine (les machines, les travailleurs, les matières premières) nécessaires pour fabriquer ce widget [x]. – cdwilson

Répondre

4

Pour chaque projet, ajouter .git/crochets/pre-commit (et assurez-vous qu'il est exécutable):

#!/bin/sh 
git --git-dir=~/eagle/.git log -1 --pretty=format:%H >.eagle_rev 
git add .eagle_rev 

Ensuite, pour chaque projet:

git config alias.update-eagle '!git --git-dir=~/eagle/.git --work-tree=~/eagle checkout -q $(<.eagle_rev)' 

Lorsque vous effectuez une commettras , il va enregistrer la tête actuelle de ~/eagle, et git update-eagle va vérifier ce commit dans ~/eagle. (Ensuite, assurez-vous de git checkout <branch> dans ~/eagle avant d'y apporter des modifications.)

+0

mkarasek, vous êtes la nouvelle hotness! Je n'avais aucune idée des hooks jusqu'à présent ... Cependant, pour une raison quelconque, l'utilisation de "~" dans le chemin --git-dir renvoyait l'erreur "fatal: Not a git repository: '~/eagle/.git'". Cependant, si j'ai remplacé "~" par "$ HOME" (c'est-à-dire '--git-dir = $ HOME/eagle/.git') cela fonctionne très bien. Une idée de pourquoi "~" ne fonctionne pas avec --git-dir et --work-tree? – cdwilson

+0

Vous obtenez cette erreur avec le crochet de validation? Peut-être que votre/bin/sh a des problèmes avec cela; remplacez la première ligne par #!/bin/bash et voyez si cela résout le problème. (Si, d'autre part, vous obtenez cette erreur avec l'alias, alors je n'en ai aucune idée.) – mkarasek

0

Si eagle n'a pas sa place dans un ProjX,
mais chaque ProjX peut utiliser une révision spécifique de eagle,
alors:

Pour chaque ProjX, vous devez:

  • avoir un Git repo, dans laquelle vous trouverez:
    • un ProjX
    • une version de eagle (au même niveau que ProjX)

L'objectif de chaque projet parent MainProjX est de garder ensemble les versions de ProjX et eagle , c'est-à-dire enregistrer les bonnes dépendances.

~/projects/ <-- Projects folder 
    MainProj0 
     Proj0/ 
      .git/ 
      <design files> 
     eagle/ 
      .git/ 
      <library files> 

    MainProj1 
     Proj1/ 
      .git/ 
      <design files> 
     eagle/ 
      .git/ 
      <library files> 

Maintenant, oui, c'est beaucoup de duplication « eagle », mais ce qui est nécessaire si chaque ProjX est en mesure d'utiliser sa propre eagle révision.

+0

VonC, merci pour la réponse rapide. Ouais, c'était la seule chose que je pouvais trouver ... Le problème est que le repo 'eagle' pourrait être vraiment énorme (une bibliothèque cad complète) alors que les repos de Proj [x] sont vraiment petits. Comme vous l'avez dit, je devrais garder des tonnes de copies des repos 'eagle', ET pire encore, je devrais changer manuellement le chemin de la bibliothèque de l'outil de CAO vers l'individu Proj [x]/eagle/dir pour le outil pour les voir même, ce qui rend cette méthode pratiquement inutilisable. – cdwilson

+1

@lotharsmash: un chemin relatif "' ../aigle' "ne suffirait-il pas pour chaque chemin de bibliothèque? (puisque 'eagle' serait au même niveau que' ProjX') – VonC