From: Mattia Rigotti Date: Sun, 7 Jul 2013 03:09:58 +0000 (-0400) Subject: Added it/drawbacks.txt X-Git-Url: https://repo.or.cz/w/gitmagic.git/commitdiff_plain/b7d16d83bb671fa8cf3dacfe2df48737be81f641 Added it/drawbacks.txt --- diff --git a/it/drawbacks.txt b/it/drawbacks.txt new file mode 100644 index 0000000..c072eca --- /dev/null +++ b/it/drawbacks.txt @@ -0,0 +1,185 @@ +== Appendice A: Le lacune di Git == + +Git presenta qualche problema che ho nascosto sotto il tappeto. Alcuni +possono essere facilmente risolti con script e 'hook', altri richiedono +di riorganizzare e ridefinire il progetto, e per le poche rimanenti +seccature non vi rimarrà che attendere. O meglio ancora, contribuire +con il vostro aiuto! + +=== Le debolezze di SHA1 === + +Con il tempo, gli specialisti in crittografia continuano a scoprire +debolezze di SHA1. È già possibile trovare collisioni hash (cioè +sequenze di byte che risultano nello stesso codice hash), dati +sufficienti mezzi. Fra qualche anno anche un normale PC potrebbe avere +abbastanza potenza di calcolo per corrompere in maniera non rilevabile +un deposito Git. + +Auspicabilmente Git sarà migrato verso un migliore sistema di funzioni +hash prima che ulteriore ricerca distruggerà lo standard SHA1. + +=== Microsoft Windows === + +Git per Microsoft Windows può essere piuttosto ingombrante: + +- http://cygwin.com/[Cygwin] è un ambiente di emulazione di Linux per + Windows che contiene http://cygwin.com/packages/git/[una versione di + Git per Windows]. + +- http://code.google.com/p/msysgit/[Git per MSys] è un alternativa che + richiede meno risorse, anche se alcuni comandi necessitano ancora di + essere migliorati. + +=== File senza relazione === + +Se il vostro progetto è molto grande e contiene molti file scorrelati +che tendono a cambiare spesso, Git può essere in svantaggio rispetto ad +altri sistemi perché file singoli non sono tenuti sotto controllo. Git +tiene sotto controllo l'intero progetto, che normalmente è una strategia +vantaggiosa. + +Una soluzione è di suddividere il vostro progetto in pezzi, ognuno +consistente di gruppi di file correlati. Usate *git submodule* se volete +poi comunque mantenere tutto in un deposito unico. + +=== Chi modifica cosa? === + +Certi sistemi di controllo di versione vi obbligano a marcare +esplicitamente un file prima di poterlo modificare. Mentre questo è +particolarmente fastidioso perché implica comunicazioni addizionali con +un server centrale, ha comunque due benefici: + + 1. Il calcolo delle differenze è rapido, perché solo i file marcati + devono essere esaminati. + + 2. Ognuno può sapere chi sta lavorando su un file chiedendo al server + centrale chi l'ha marcato per modifiche. + +Con qualche script appropriato, potete ottenere la stessa cosa con Git. +Questo richiede cooperazione dagli altri programmatori, i quali devono +eseguire script particolari prima di modificare un file. + +=== La storia di un file === + +Perché Git registra modifiche in maniera globale al progetto, la +ricostruzione della storia di un singolo file richiede più lavoro che in +altri sistemi di controllo di versioni che si occupano di file +individuali. + +Questo sovrappiù è generalmente trascurabile e ne vale la pena visto che +permette altre operazioni di incredibile efficienza. Per esempio, `git +checkout` è più rapido che `cp -a`, e una differenza di versione globale +al progetto si comprime meglio che una collezione di differenze di file +individuali. + +=== Il clone iniziale === + +Creare un clone è più costoso che fare un checkout in altri sistemi di +controllo di versione se il progetto ha una storia lunga. + +Il costo iniziale è un buon investimento, visto che operazioni future +saranno più rapide e offline. Tuttavia, in alcune situazioni può essere +preferibile creare un clone superficiale utilizzando l'opzione +`--depth`. Questo è più rapido, ma il clone risultante ha funzionalità +limitate. + +=== Progetti volatili === + +Git è stato scritto per essere rapido rispetto alla dimensione dei +cambiamenti. Normalmente si tende a fare piccole modifiche da una +versione all'altra. La correzione di un bug in una linea qui, una nuova +funzionalità là, commenti corretti, e così via. Ma se i vostri file +cambiano radicalmente in revisioni successive, ad ogni commit la vostra +storia crescerà necessariamente proporzionalmente alle dimensioni +dell'intero progetto. + +Non c'è niente che nessun sistema di controllo di versione possa fare +per evitare questo, ma gli utilizzatori di Git ne soffriranno di più +perché ogni clone contiene normalmente la storia completa. + +Bisogna cercare la ragione per cui questi cambiamenti sono così grandi. +Magari bisogna cambiare il formato dei file. Modifiche minori dovrebbero +causare solo cambiamenti minori in solo pochi file. + +Magari un database o un sistema d'archivio sono invece una soluzione più +adatta invece di un sistema di controllo di versione. Per esempio, un +sistema di controllo di versione potrebbe non essere adatto per gestire +fotografie prese periodicamente da una webcam. + +Se i file devono essere cambiare radicalmente e se devono essere gestite +in versioni, una possibilità è di usare Git in maniera centralizzata. È +possibile creare cloni superficiali che contengono solo una parte minore +o addirittura inesistente della storia del progetto. Naturalmente in +questo caso molti strumenti di Git non saranno più a disposizione, e +correzioni dovranno essere fornite sotto forma di patch. Questo va +probabilmente bene, visto che non sembrerebbe doverci essere nessun +motivo per mantenere la storia di file ampiamente instabili. + +Un altro esempio è un progetto che dipende da un firmware che consiste +in un enorme file binario. La storia di questo firmware non interessa +agli utilizzatori, e gli aggiornamenti non sono molto compressibili, il +che significa che le revisioni del firmware inflazionano inutilmente il +deposito. + +In questo caso il codice sorgente dovrebbe essere salvato in un deposito +Git, mentre i file binari dovrebbero essere tenuti separatamente. Per +rendere la vita più facile, si potrebbe distribuire uno script che usa +Git per clonare il codice sorgente, e rsync o un Git superficiale per il +firmware. + +=== Contatore globale === + +Alcuni sistemi di controllo di versione centralizzati mantengono un +numero intero che aumenta quando un nuovo commit è accettato. Git fa +riferimento ai cambiamenti tramite il loro codice hash, un metodo +migliore in molte circostanze. + +Alcune persone vorrebbero però avere accesso a questo contatore. +Fortunatamente è facile scrivere uno script che fa in maniera di +aumentare un contatore nel deposito Git centrale ad ogni aggiornamento, +magari grazie ad una tag associata con un hash dell'ultimo commit. + +Ogni clone potrebbe mantenere un tale contatore, ma questo sarebbe +probabilmente inutile, visto che solo il contatore del deposito centrale +è interessante per gli utenti. + +=== Sottocartelle vuote === + +Sottocartelle vuote non possono essere gestite. Create dei file +segnaposto per rimediare a questo problema. + +Queste limitazioni non sono dovute a come Git è concepito, ma piuttosto +a come è correntemente implementato. Con un po' di fortuna, se +abbastanza utilizzatori lo richiedono, questa funzionalità potrebbe +essere implementata. + +=== Commit iniziale === + +In informatico tipico conta a partire da 0, invece che da 1. +Sfortunatamente, rispetto ai commit, Git non aderisce a questa +convenzione. Molti comandi non funzionano prima del primo commit. +Inoltre alcuni casi limite devono essere gestiti in maniera specifica: +ad esempio, usare 'rebase' su una branch con commit iniziale diverso. + +Git beneficerebbe della definizione del commit numero zero: non appena +un deposito è costruito, HEAD verrebbe assegnato ad una stringa +consistente in 20 bytes zero. Questo commit speciale rappresenterebbe un +tree vuoto, senza genitori, che sarebbe presente in tutti i depositi +Git. + +In questo modo ad esempio l'esecuzione di 'git log' informerebbe +l'utente che non sono ancora stati fatti commit, invece di terminare con +un 'fatal error'. Una cosa simile varrebbe per altri comandi. + +Ogni commit iniziale sarebbe implicitamente discendente da questo commit +zero. + +Ci sarebbero tuttavia casi problematici. Se diverse branch con commit +iniziali diversi fossero fusi assieme con un merge, l'uso del comando +'rebase' richiederebbe un sostanziale intervento manuale. + +=== Bizzarrie dell'interfaccia === + +Dati due commit A e B, il significato delle espressioni "A..B" e "A...B" +dipende da se il comando si attende due estremità o un intervallo. +Vedete *git help diff* e *git help rev-parse*.