Deux référentiels git dans un répertoire?

Est-il possible d'avoir 2 référentiels git dans un répertoire? Je ne pense pas, mais j'ai pensé que je demanderais. Fondamentalement, j'aimerais archiver les fichiers de configuration de mon répertoire personnel (par exemple .emacs) qui devraient être communs à toutes les machines sur lesquelles je travaille, mais avoir un deuxième référentiel pour les fichiers locaux (par exemple .emacs.local), qui contient configurations spécifiques à la machine. La seule façon dont je peux penser pour faire cela est d'avoir la configuration locale dans un sous-répertoire et d'ignorer ce sous-répertoire du référentiel git principal. D'autres idées?

Si je comprends ce que vous faites, vous pouvez tout gérer dans un seul référentiel, en utilisant des branches séparées pour chaque machine, et une branche contenant vos fichiers de configuration de répertoire de base communs.

Initialisez le référentiel et livrez-y les fichiers communs, en renommant peut-être la branche MASTER en Common. Créez ensuite une branche distincte à partir de là pour chaque machine avec laquelle vous travaillez et validez 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 de la machine et poussez vers vos autres machines (écrivez un script pour cela s'il y en a beaucoup).

Ensuite, sur chaque machine, vérifiez la branche de cette machine, qui comprendra également les fichiers de configuration courants.

Cet article couvre cela relativement bien:

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

Fondamentalement, si vous travaillez à partir de la ligne de commande, c'est plus simple que vous ne le pensez. Supposons que vous vouliez 2 dépôts git:

.gitone
.gittwo

Vous pouvez les configurer comme ceci:

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

Vous pouvez ajouter un fichier et le valider dans un seul comme ceci:

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

Ainsi, les options pour git viennent en premier, puis la commande, puis les options de la commande git. Vous pouvez facilement aliaser une commande git comme:

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

Vous pouvez donc vous engager dans l'un ou l'autre avec un peu moins de frappe, comme gitone commit -m "blah".

Ce qui semble devenir plus délicat est ignoré. Étant donné que .gitignore se trouve normalement à la racine du projet, vous devez également trouver un moyen de changer cela sans changer la racine entière. Ou, vous pouvez utiliser .git / info / exclude, mais tous les ignorés que vous effectuez alors ne seront pas validés ou poussés - ce qui pourrait gâcher d'autres utilisateurs. D'autres utilisant l'un ou l'autre des référentiels peuvent pousser un .gitignore, ce qui peut provoquer des conflits. La meilleure façon de résoudre ces problèmes n'est pas claire pour moi.

Si vous préférez les outils GUI comme TortoiseGit, vous aurez également des défis. Vous pouvez écrire un petit script qui renomme temporairement .gitone ou .gittwo en .git afin que les hypothèses de ces outils soient satisfaites.

Jetez un œil au sous-module git .

Les sous-modules permettent aux référentiels étrangers d'être intégrés dans un sous-répertoire dédié de l'arborescence source, toujours pointé vers un commit particulier.

RichiH a écrit un outil appelé vcsh qui est un outil pour gérer les fichiers 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 aviez plusieurs répertoires, une alternative aux git-submodules (qui sont pénibles dans le meilleur des cas et cet exemple d'utilisation n'est pas la meilleure des circonstances) est gitslave qui laisse les dépôts esclaves vérifiés sur la pointe d'un branchez à tout moment et ne nécessite pas le processus en trois étapes pour effectuer une modification dans le dépôt subsidiaire (extraire la bonne branche, effectuer et valider la modification, puis aller dans le superprojet et valider le nouveau commit de sous-module).

C'est possible en utilisant la variable GIT_DIRmais comporte de nombreuses mises en garde si vous ne savez pas ce que vous faites.

Ouais, les sous-modules sont probablement ce que vous voulez. Une autre option serait d'avoir votre copie de travail dans un sous-répertoire, puis de pointer des liens symboliques de votre répertoire personnel vers les fichiers d'intérêt.

ma méthode préférée utilise un dépôt dans un sous-répertoire et utilise des liens symboliques récursifs:

git clone repo1
cd somerepo
git clone repo2
cd repo2
./build

où le fichier ' repo / build ' ressemble à:

#!/bin/bash 
SELF_PATH="$(dirname "$(readlink -f "$0")" )"  # get current dir 
cd .. && git stash && git clean -f -d ''       # remove previous symlinks
cp -sR "$SELF_PATH"/* ../.                     # create recursive symlinks in root

attention : n'utilisez pas 'git add.'

L'autre option consiste à les placer sur des dossiers séparés et à créer des liens symboliques durs d'un dossier à l'autre.

Par exemple, s'il y a les référentiels:

1. Repo1 / DossierA
2. Repo1 / DossierB

Et:

1. Repo2 / DossierC

Vous pouvez créer un lien symbolique entre les dossiers FolderAet FolderBle Repo1 dans le Repo2. Pour Windows, la commande à exécuter sur le Repo1 serait:

User@Repo1$ mklink /J FullPath/Repo2/FolderA FullPath/Repo1/FolderA
User@Repo1$ mklink /J FullPath/Repo2/FolderB FullPath/Repo1/FolderB
User@Repo1$ printf "/FolderA/*\n/FolderB/*\n" >> .gitignore

Pour les fichiers sur les référentiels principaux, vous devez créer un lien symbolique pour chacun d'eux, en les ajoutant également au référentiel .gitignorepour éviter le bruit, sauf si vous le souhaitez.

Avertissement: ce n'est pas de la publicité. Je suis le développeur de la bibliothèque fournie.

J'ai créé une extension git pour gérer les cas où vous souhaitez mélanger plusieurs référentiels dans un seul dossier. L'avantage de la lib est de garder une trace des référentiels et des conflits de fichiers. vous pouvez le trouver sur github . Il existe également 2 exemples de référentiels pour l'essayer.