Partager un arbre travaillant avec des sous-modules git

Question

Supposons que j'ai une bibliothèque Common qui peut être utilisé de manière autonome et est utilisé par des projets P1 et P2, de sorte que l'arbre que je veux ressemble

/Common/.git 
     ... 
/P1/.git 
    .gitmodules # points to remote server 
    Common/ 
    ... 
/P2/.git 
    .gitmodules # points to remote server 
    Common/ 
    ... 

Quand je fais un changement dans /Common, je voudrais être en mesure de le tester en utilisant P1 et P2 avant de commettre. Avec le jeu de commandes git submodule habituel, je devrais valider à partir de /Common, pousser à distance, puis tirer à la fois /P1/Common et /P2/Common. Si le commit casse quelque chose, il ne peut pas être modifié car le mauvais changement a déjà été publié. Sinon, je pourrais git remote add quicktest /Common de /P?/Common pour pouvoir tirer sans toucher le serveur distant. Mais cela a beaucoup de possibilités d'incohérence et il est sale de supprimer les commits rompus de /P?/Common afin qu'ils puissent être modifiés en /Common.

Je préférerais que, au cours du développement, l'arbre de travail de /Common être utilisé par P1 et P2, mais je ne peux pas faire un lien symbolique /P1/Common à /Common car git submodule reconnaît le lien symbolique comme différent d'un répertoire. Les répertoires hardlinking ne sont pas autorisés par la plupart des systèmes de fichiers. Je peux HardLink tous les fichiers en utilisant

rm -rf /P1/Common 
cp -rl /Common /P1/Common 

qui fonctionne très bien jusqu'à ce qu'un nouveau fichier est ajouté à /Common dans ce cas, ce processus doit être répété. Y at-il une façon élégante à la fois

1. garder git clone --recursive git://remote/P1.git travailler pour l'utilisateur final, et
2. me permettent de tester facilement que les changements dans /Common travail avec P1 et P2?

Answer 1

Je préfère établir un repo nu intermédiaire où:

• pousser Common nouveaux commits
• tirer de pour P1/Common et P2/Common

Au moins, si commits sont modifiées/supprimé plus tard, ce rapport intermédiaire n'a jamais été publié à l'extérieur et vous pouvez toujours réinitialiser vos sous-modules P1/Common et P2/Common à t le contenu du repo intermédiaire.

Answer 2

Essayez la fonction git worktree depuis git 2.5.

1. Supprimer /P1/Common
2. cd /Common
3. Créer P1 branche pour la venue /P1/Common arbre de travail
4. run git worktree add ../P1/Common P1

Faites la même chose sur /P2.Ensuite, /P1/Common, /P2/Common and/Commun working trees share the same repository/Commun/.git.

Et vous pouvez facilement récupérer tout commit qui est engagé dans un autre arbre de travail.

P.S. vous pouvez toujours utiliser la commande git submodule pour un travail quotidien avec cette fonctionnalité git worktree.