Invio di sottostrutture in un repository git

Question

Sono abbastanza nuovo per Git: Vengo da SVN e ho trovato molto potente la funzione: esterna. Qui in Git non ho trovare qualcosa di simile:

• sottomoduli sono perfetti per l'aggiunta di moduli di progetto che non sono sempre necessari. Devono essere inizializzati dopo la clonazione del repository e non è possibile includere solo una sottodirectory del progetto originale.
• i sottotitoli sono veramente buoni per l'aggiunta di librerie (consentono anche l'inclusione di sottodirectory), ma spingerli è un vero dolore.

Quindi lo scenario è questo: Ho un progetto, nel quale voglio includere alcune librerie. Voglio la possibilità di cambiare tutte queste librerie e inserirle nei propri repository. Inoltre alcune di queste librerie sono sottodirectory di progetti più grandi (per esempio se un progetto include anche demo o file readme, non includerò quelle dir nel mio progetto).

Come posso farlo?

ho provato:

• http://progit.org/book/ch6-7.html + http://posterous.timocracy.com/git-sub-tree-merging-back-to-the-subtree-for (merging solo una sottocartella non è permesso, o non posso vederlo);
• http://www.tipstank.com/2011/02/21/git-subtree-notes-and-workflows/ (come sopra, non gestire l'inclusione di subdir);
• http://psionides.eu/2010/02/04/sharing-code-between-projects-with-git-subtree/ (non può vedere nulla di spingere);
• http://h2ik.co/2011/03/having-fun-with-git-subtree/ (non riesco a vedere nulla di spingere)

Bene, se hai raggiunto questo punto, grazie per la vostra pazienza, ora vorrei qualcosa di diverso da provare, perché in questo momento la mia conclusione è : "sottostruttura spingendo non è consentito in Git" ç_ç

Answer 1

paio di osservazioni dai commenti:

• git submodules are different from svn external
• ogni modifica fatta a un modulo 012.392..
• "Planning repository layout for git migration" illustra che non è sempre possibile utilizzare i sottomoduli direttamente poiché la struttura della directory non sarebbe esattamente quella di cui si ha bisogno.

quindi vi consiglio:

• caricamento (git checkout) il repo genitore e tutti i suoi sottomoduli
• creare altrove la struttura corretta, con link simbolico per sottomoduli (o sottodirectory di sottomoduli in ordine per ottenere ciò che ti serve
• torna periodicamente al repository git ain padre per rilevare eventuali modifiche (doni dall'altra struttura di directory creata al di fuori di Git) per commettere e inviare tutti i moduli dei sottomoduli, quindi eseguire il commit e spingere il repository padre.

git checkout

parent repo 
    + 
    +--> main project 
    + 
    +-> mainDir1 
    +-> mainDir2 
    +--> lib1 
    + 
    +-> lib1Dir1 
    +-> lib1Dir2 
    +--> lib2 
    + 
    +-> lib2Dir1 
    +-> lib2Dir2 

e la propria struttura di directory del progetto (per esempio)

+--> main project (symlink to ../parent/main project) 
    + 
    +-> mainDir1 
    +-> mainDir2 
    +-> lib1Dir1 (symlink to ../parent/lib1/lib1Dir1) 
    +-> lib1Dir2 (symlink to ../parent/lib1/lib1Dir2) 
    +-> lib2Dir2 (symlink to ../parent/lib1/lib2Dir2) 

(notare non c'è lib2Dir1 (per esempio) perché nel progetto attuale si don' ne ho bisogno)

Answer 2

La soluzione di VonC è pulita, ma ha uno svantaggio: Non c'è nessuno un modo per catturare una configurazione del tuo progetto + librerie in un determinato momento.

Se è necessario configurare di nuovo il progetto, è necessario verificare il progetto + le biblioteche, ma potrebbero essere tutte su rami diversi e si impegna a ciò che si era in precedenza.

Quindi, se si segue il suggerimento di VonC, magari creare tag in ciascuno dei repository nel momento in cui si rilascia un progetto, in modo che sia possibile controllarli di nuovo nello stesso punto.

In caso contrario, spostare sempre in avanti e non verificare mai una versione precedente.