Due repository git in una directory?

È ansible avere 2 repository git in una directory? Non penserei, ma ho pensato di chiederlo. Fondamentalmente, mi piacerebbe controllare i miei file di configurazione della directory home (ad esempio .emacs) che dovrebbero essere comuni su tutte le macchine su cui lavoro, ma ho un secondo repository per i file locali (ad esempio .emacs.local), che contiene configurazioni specifiche della macchina. L’unico modo che posso pensare di fare è avere la configurazione locale in una sottodirectory e ignorare quella sottodirectory dal repository git principale. Altre idee?

Se capisco cosa stai facendo, puoi gestirlo tutto in un unico repository, usando rami separati per ogni macchina, e un ramo contenente i tuoi file di configurazione della directory home più comuni.

Inizializza il repository e memorizza i file comuni su di esso, forse rinominando il ramo MASTER come Comune. Quindi creare un ramo separato da lì per ogni macchina con cui si lavora e trasferire file specifici della macchina in quel ramo. Ogni volta che si cambiano i file comuni, unire il ramo comune in ciascuno dei rami macchina e passare alle altre macchine (scrivere uno script per questo se ce ne sono molti).

Quindi, su ciascuna macchina, controlla il ramo della macchina, che includerà anche i file di configurazione comuni.

Questo articolo tratta relativamente bene:

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

Fondamentalmente se stai lavorando dalla riga di comando questo è più semplice di quanto tu possa immaginare. Supponiamo di volere 2 repository git:

 .gitone .gittwo 

Potresti installarli in questo modo:

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

Puoi aggiungere un file e assegnarlo a uno solo in questo modo:

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

Quindi vengono prima le opzioni per git, poi il comando, quindi le opzioni del comando git. Si potrebbe facilmente abbastanza alias un comando git come:

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

Così puoi impegnarti con l’uno o l’altro digitando un po ‘meno, come gitone commit -m "blah" .

Quello che sembra essere più ingannevole è ignorare. Dato che .gitignore si trova normalmente nella root del progetto, è necessario trovare un modo per cambiare anche questo senza cambiare l’intera radice. In alternativa, puoi utilizzare .git / info / exclude, ma tutte le ignorazioni che esegui non verranno né sottoposte a commit o push, il che potrebbe rovinare altri utenti. Altri che utilizzano uno dei due repo potrebbero premere un segno di memoria, che potrebbe causare conflitti. Non mi è chiaro il modo migliore per risolvere questi problemi.

Se preferisci strumenti GUI come TortoiseGit, avrai anche alcune sfide. Potresti scrivere un piccolo script che rinomina temporaneamente .gitone o .gittwo in .git in modo da soddisfare le ipotesi di questi strumenti.

Dai un’occhiata al sottomodulo git .

I sottomoduli consentono di incorporare i repository stranieri all’interno di una sottodirectory dedicata dell’albero dei sorgenti, sempre puntata su un particolare commit.

RichiH ha scritto uno strumento chiamato vcsh che è uno strumento per gestire i dotfile usando i falsi repository finti di git per inserire più di una directory di lavoro in $ HOME. Niente a che vedere con csh AFAIK.

Comunque, se tu avessi più directory, un’alternativa ai sottomodelli git (che sono un dolore nel migliore delle circostanze e questo esempio di utilizzo non è il migliore delle circostanze) è gitslave che lascia il repository slave controllato sulla punta di un branch in ogni momento e non richiede il processo in tre fasi per effettuare una modifica nel repository sussidiario (eseguire il checkout sul ramo corretto, effettuare il commit e confermare la modifica, quindi accedere al superproject e confermare il commit del nuovo submodule).

È ansible usando la variabile GIT_DIR ma ha molti avvertimenti se non sai cosa stai facendo.

Sì, i sottomoduli sono probabilmente quello che vuoi. Un’altra opzione sarebbe quella di avere la tua copia di lavoro in una sottodirectory e quindi puntare i link simbolici dalla tua home directory ai file di interesse.

il mio metodo preferito è l’utilizzo di un repository in una sottodirectory e l’utilizzo di collegamenti simbolici ricorsivi:

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

dove appare il file ‘ repo / build ‘:

 #!/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 

attenzione : non usare ‘git add.’

L’altra opzione è per loro su cartelle separate e creare hard link simbolici da una cartella all’altra.

Ad esempio, se ci sono i repository:

  1. Repo1 / FolderA
  2. Repo1 / FolderB

E:

  1. Repo2 / FolderC

È ansible FolderA simbolicamente le cartelle FolderA e FolderB da Repo1 a Repo2. Per Windows il comando da eseguire su Repo1 sarebbe:

 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 

Per i file sui repository principali è necessario associarli a link simbolici, aggiungendoli anche al repository .gitignore per evitare rumore, a meno che non lo si voglia.

Disclaimer: questa non è pubblicità. Sono lo sviluppatore della libreria fornita.

Ho creato un’estensione git per gestire casi in cui si desidera mescolare più repository in una cartella. Il vantaggio della lib è, per tenere traccia dei repository e dei conflitti di file. lo puoi trovare su github . Ci sono anche 2 repository di esempio da provare.