Perché i sottomoduli git sono incompatibili con gli svn esterni?

Ci sono un sacco di pagine web che suggeriscono modi incredibili di rendere gli esterni di svn come sottomodelli di git . Ho letto alcuni resoconti su quale sia la differenza, ma questo non sembra molto fondamentale:

I sottomoduli Git si collegano a un particolare commit nel repository di un altro progetto, mentre svn: externals recupera sempre l’ultima revisione.

Perché questa differenza li rende così fondamentalmente incompatibili? Non c’è un default ragionevole che possiamo supporre, come ad esempio che la maggior parte di svn: esterni punta a tag che non si spostano mai?

La differenza fondamentale è la regola della composizione .

In un vero approccio basato su componenti , si definisce una configurazione , ovvero:
L’elenco delle etichette (di SHA1 si impegna per Git) di cui hai bisogno per “lavorare” (cioè “sviluppare”, “compilare”, “distribuire”, …).

Ogni commit referenziato in una configurazione ti aiuta a ottenere le esatte versioni di tutti gli alberi. Non c’è eccezione. Ogni file di quell’albero è nella versione esatta specificata dalla configurazione che hai definito.


Nota per git1.8.2

“git submodule” ha iniziato ad apprendere una nuova modalità da integrare con la punta del ramo remoto (anziché l’integrazione con il commit registrato nel gitlink del superprogetto).

Così presto (marzo 2013), un sottomodulo potrebbe fare riferimento a un HEAD a monte e non solo a un SHA1 fisso.


(Prima di 1.8.2) Può esserci solo un’etichetta / SHA1 per modulo. Da un repository padre comune, non è ansible definire un modulo all’interno di un modulo.
(Ma un modulo, che è solo un riferimento a un repository Git esterno, può avere la propria definizione di sottomoduli: il repository padre si riferirà solo al sottomodulo di primo livello, che a sua volta farà riferimento a qualsiasi sottomodulo che aveva commesso dentro di sé)


No in SVN esterno : è ansible definire directory esterne e file esterni, con o senza una revisione esplicita in esso.
È ansible comporre varie proprietà esterne. Per esempio:

$ svn propget svn:externals calc third-party/sounds http://svn.example.com/repos/sounds third-party/skins -r148 http://svn.example.com/skinproj third-party/skins/toolkit -r21 http://svn.example.com/skin-maker 

Il risultato non è una configurazione (un riferimento per ‘ calc ‘), ma una composizione di regole di selezione che definiscono l’esatta “patchwork” di cui hai bisogno nella directory ‘ calc


In breve, non è ansible “calcolare” un SHA1 per un sottomodulo ” calc ” che sarebbe l’equivalente esatto di un gruppo di svn:external proprietà svn:external su una directory SVN ” calc “.

Se si utilizza SmartGit per lavorare con il repository SVN con svn: externalls, non si noterà alcuna reale differenza.

In realtà, l’unica vera differenza (almeno l’unica differenza tecnica) è che SVN consente a external di puntare alla revisione HEAD (non a valore fisso), il sottomodulo Git no. Tutte le altre differenze sono, a mio parere, insignificanti, quindi hai ragione a fare questa domanda.