2013-04-23 7 views
5

Una recente modifica di Git ha cambiato il modo in cui viene gestita la directory .git quando si utilizzano i sottomoduli. Invece di avere uno .git per sottomodulo, tutto è ora nella directory "root level" .git (quella corrispondente alla copia di lavoro inclusi i sottomoduli).Spostamento di una copia di lavoro di git contenente sottomoduli

Quindi, in ogni sottomodulo, viene creato un file che punta alla nuova posizione della directory .git.

In my project, ho il .gitmodules del file seguente:

[submodule "tests/shared-tests"] 
     path = tests/shared-tests 
     url = git://github.com/roboptim/roboptim-shared-tests.git 
[submodule "cmake"] 
     path = cmake 
     url = git://github.com/jrl-umi3218/jrl-cmakemodules.git 

Quando faccio git clone --recursive, ho quindi ottenere:

$ cat cmake/.git 
gitdir: /home/moulard/profiles/default-x86_64-linux-ubuntu-12.04.1/src/unstable/roboptim/roboptim-core/.git/modules/cmake 

Attualmente sto usando Git 1.8.1.5.

Le mie domande sono:

  1. Perché ha fatto questo cambiamento di comportamento? Non vedo alcun guadagno ovvio a questa nuova strategia.
  2. Come posso quindi spostare in modo sicuro una copia di lavoro? (Se sposto la mia copia di lavoro, ricevo un messaggio di errore che mi dice che il percorso del gitdir rotta non è più un repository Git)

Si prega di notare che questa non è la stessa della domanda precedente Moving the parent directory of a git repository that contains submodules nel Sento che sono sicuro questo non è un problema correlato alla presenza di un percorso assoluto nel mio file .gitmodules.

risposta

8

L'organizzazione .git/module risale da git1.7.8 (December 2d, 2011):

Quando si popola una nuova directory modulo con "git submodule init", la directory $GIT_DIR metainformation per sottomoduli viene creato all'interno $GIT_DIR/modules/<name>/ directory del SuperProject e fa riferimento tramite il meccanismo gitfile.
Ciò consente di passare da un commit all'altro nel superprogetto che ha e non ha il sottomodulo nell'albero senza ripetere la clonazione.

Tuttavia, correzioni di bug più recenti sono stati inclusi in 1.8.2.1 e 1.8.3 (aprile 22d, 2013):

, quando ricorsivo in sotto-moduli, non acccumulate i percorsi prefisso "git aggiornamento modulo" .

Quindi l'aggiornamento all'ultima release di Git potrebbe risolvere questo problema.


Qui, una possibile soluzione (con l'ultima git 1.8.3, Aprile, 22d 2013), è menzionato dal OP Thomas Moulard in the comments:

$ git submodule deinit -f . sta lavorando!
Poi posso correre git submodule init ei sentieri ottenere fisso

Questo si prende cura se i (de) passi di inizializzazione (.git/modules)

non prende cura del 'add' passo che registra la url di un sottomodulo nel file .gitmodules: è ancora necessario rimuoverlo manualmente all'interno di quel file.

+0

Se tutto fallisce, allora forse http://stackoverflow.com/a/15504813/6309? – VonC

+0

in realtà ho provato con l'ultima versione di Git e l'HEAD di master ma finora non ho avuto fortuna a meno che non ci sia un comando git di cui non sono a conoscenza ... –

+0

@ThomasMoulard è il più recente 1.8.3 nel tuo caso? – VonC

1

ho fissato con successo la mia copia di lavoro dopo averlo spostato a fare altrove il seguente:

  • Aggiornamento del file gitdir: percorso nel superproject/path/to/submodule/.git
  • Aggiornamento del percorso worktree= in superproject/.git/modules/path/to/submodule/config file di

I don' So perché Git usa percorsi assoluti lì!

(testato su git 2.0.1.563)