Deux dépôts git dans un même répertoire ?

Question

Est-il possible d'avoir 2 dépôts git dans un même répertoire ? Je pense que non, mais j'ai pensé poser la question. En gros, j'aimerais vérifier dans mon répertoire personnel les fichiers de configuration (par exemple .emacs) qui devraient être communs à toutes les machines sur lesquelles je travaille, mais avoir un second dépôt pour les fichiers locaux (par exemple .emacs.local), qui contient des configurations spécifiques à la machine. Le seul moyen auquel je pense pour faire cela est d'avoir la configuration locale dans un sous-répertoire et d'ignorer ce sous-répertoire du dépôt git principal. D'autres idées ?

Answer 1

Cet article couvre relativement bien cette question :

https://github.com/rrrene/gitscm-next/blob/master/app/views/blog/progit/2010-04-11-environment.markdown

En fait, si vous travaillez en ligne de commande, c'est plus simple que vous ne le pensez. Supposons que vous vouliez 2 dépôts git :

.gitone
.gittwo

Vous pourriez les configurer de la manière suivante :

git init .
mv .git .gitone
git init .
mv .git .gittwo

Vous pourriez ajouter un fichier et le livrer à un seul comme ceci :

git --git-dir=.gitone add test.txt
git --git-dir=.gitone commit -m "Test"

Les options de git viennent donc en premier, puis la commande, puis les options de la commande git. Vous pourriez facilement aliaser une commande git de la manière suivante :

#!/bin/sh
alias gitone='git --git-dir=.gitone'
alias gittwo='git --git-dir=.gittwo'

Vous pouvez donc vous engager sur l'un ou l'autre en tapant un peu moins, comme par exemple gitone commit -m "blah" .

Ce qui semble plus délicat, ce sont les ignorés. Puisque .gitignore se trouve normalement dans la racine du projet, il faudrait trouver un moyen de le changer aussi sans changer toute la racine. Vous pouvez également utiliser .git/info/exclude, mais tous les ignores que vous effectuez alors ne seront pas validés ou poussés - ce qui pourrait perturber les autres utilisateurs. D'autres personnes utilisant l'un ou l'autre repo pourraient pousser un .gitignore, ce qui pourrait causer des conflits. Je ne vois pas clairement la meilleure façon de résoudre ces problèmes.

Si vous préférez les outils à interface graphique comme TortoiseGit, vous aurez également quelques difficultés. Vous pourriez écrire un petit script qui renomme temporairement .gitone ou .gittwo en .git afin que les hypothèses de ces outils soient respectées.

Answer 2

Si je comprends bien ce que vous faites, vous pouvez tout gérer dans un seul dépôt, en utilisant des branches séparées pour chaque machine, et une branche contenant les fichiers de configuration de votre répertoire personnel commun.

Initialiser le repo et y livrer les fichiers communs, en renommant éventuellement la branche MASTER en Common. Ensuite, créez une branche séparée pour chaque machine avec laquelle vous travaillez, et livrez les fichiers spécifiques à la machine dans cette branche. Chaque fois que vous modifiez vos fichiers communs, fusionnez la branche commune dans chacune des branches machines et envoyez-les à vos autres machines (écrivez un script pour cela s'il y en a beaucoup).

Ensuite, sur chaque machine, téléchargez la branche de cette machine, qui inclura également les fichiers de configuration communs.

Answer 3

Jetez un coup d'œil sur sous-module git .

Les sous-modules autorisent les d'être intégrés dans un dans un sous-répertoire dédié de l'arborescence des sources, toujours orienté vers un commit particulier.

Answer 4

RichiH a écrit un outil appelé vcsh qui est un outil pour gérer les dotfiles en utilisant les faux dépôts nus de git pour mettre plus d'un répertoire de travail dans $HOME. Rien à voir avec csh AFAIK.

Cependant, si vous avez plusieurs répertoires, une alternative aux git-submodules (qui sont pénibles dans les meilleures circonstances et cet exemple d'utilisation n'est pas le meilleur des cas) est la suivante gitslave qui laisse les dépôts esclaves vérifiés sur l'extrémité d'une branche à tout moment et ne nécessite pas le processus en trois étapes pour faire un changement dans le dépôt subsidiaire (vérifier sur la branche correcte, faire et livrer le changement, puis aller dans le superprojet et livrer le nouveau sous-module).

Answer 5

Il est possible d'utiliser la variable GIT_DIR mais comporte de nombreuses mises en garde si vous ne savez pas ce que vous faites.