it/drawbacks.txt

   1 == Appendice A: Le lacune di Git ==
   2
   3 Git presenta qualche problema che ho nascosto sotto il tappeto. Alcuni
   4 possono essere facilmente risolti con script e 'hook', altri richiedono
   5 di riorganizzare e ridefinire il progetto, e per le poche rimanenti
   6 seccature non vi rimarrà che attendere. O meglio ancora, contribuire
   7 con il vostro aiuto!
   8
   9 === Le debolezze di SHA1 ===
  10
  11 Con il tempo, gli specialisti in crittografia continuano a scoprire
  12 debolezze di SHA1. È già possibile trovare collisioni hash (cioè
  13 sequenze di byte che risultano nello stesso codice hash), dati
  14 sufficienti mezzi. Fra qualche anno anche un normale PC potrebbe avere
  15 abbastanza potenza di calcolo per corrompere in maniera non rilevabile
  16 un deposito Git.
  17
  18 Auspicabilmente Git sarà migrato verso un migliore sistema di funzioni
  19 hash prima che ulteriore ricerca distruggerà lo standard SHA1.
  20
  21 === Microsoft Windows ===
  22
  23 Git per Microsoft Windows può essere piuttosto ingombrante:
  24
  25 - http://cygwin.com/[Cygwin] è un ambiente di emulazione di Linux per
  26   Windows che contiene http://cygwin.com/packages/git/[una versione di
  27   Git per Windows].
  28
  29 - https://gitforwindows.org/[Git per Windows] è un alternativa che
  30   richiede meno risorse, anche se alcuni comandi necessitano ancora di
  31   essere migliorati.
  32
  33 === File senza relazione  ===
  34
  35 Se il vostro progetto è molto grande e contiene molti file scorrelati
  36 che tendono a cambiare spesso, Git può essere in svantaggio rispetto ad
  37 altri sistemi perché file singoli non sono tenuti sotto controllo. Git
  38 tiene sotto controllo l'intero progetto, che normalmente è una strategia
  39 vantaggiosa.
  40
  41 Una soluzione è di suddividere il vostro progetto in pezzi, ognuno
  42 consistente di gruppi di file correlati. Usate *git submodule* se volete
  43 poi comunque mantenere tutto in un deposito unico.
  44
  45 === Chi modifica cosa? ===
  46
  47 Certi sistemi di controllo di versione vi obbligano a marcare
  48 esplicitamente un file prima di poterlo modificare. Mentre questo è
  49 particolarmente fastidioso perché implica comunicazioni addizionali con
  50 un server centrale, ha comunque due benefici:
  51
  52   1. Il calcolo delle differenze è rapido, perché solo i file marcati
  53   devono essere esaminati.
  54
  55   2. Ognuno può sapere chi sta lavorando su un file chiedendo al server
  56   centrale chi l'ha marcato per modifiche.
  57
  58 Con qualche script appropriato, potete ottenere la stessa cosa con Git.
  59 Questo richiede cooperazione dagli altri programmatori, i quali devono
  60 eseguire script particolari prima di modificare un file.
  61
  62 === La storia di un file ===
  63
  64 Perché Git registra modifiche in maniera globale al progetto, la
  65 ricostruzione della storia di un singolo file richiede più lavoro che in
  66 altri sistemi di controllo di versioni che si occupano di file
  67 individuali.
  68
  69 Questo sovrappiù è generalmente trascurabile e ne vale la pena visto che
  70 permette altre operazioni di incredibile efficienza. Per esempio, `git
  71 checkout` è più rapido che `cp -a`, e una differenza di versione globale
  72 al progetto si comprime meglio che una collezione di differenze di file
  73 individuali.
  74
  75 === Il clone iniziale ===
  76
  77 Creare un clone è più costoso che fare un checkout in altri sistemi di
  78 controllo di versione se il progetto ha una storia lunga.
  79
  80 Il costo iniziale è un buon investimento, visto che operazioni future
  81 saranno più rapide e offline. Tuttavia, in alcune situazioni può essere
  82 preferibile creare un clone superficiale utilizzando l'opzione
  83 `--depth`. Questo è più rapido, ma il clone risultante ha funzionalità
  84 limitate.
  85
  86 === Progetti volatili ===
  87
  88 Git è stato scritto per essere rapido rispetto alla dimensione dei
  89 cambiamenti. Normalmente si tende a fare piccole modifiche da una
  90 versione all'altra. La correzione di un bug in una linea qui, una nuova
  91 funzionalità là, commenti corretti, e così via. Ma se i vostri file
  92 cambiano radicalmente in revisioni successive, ad ogni commit la vostra
  93 storia crescerà necessariamente proporzionalmente alle dimensioni
  94 dell'intero progetto.
  95
  96 Non c'è niente che nessun sistema di controllo di versione possa fare
  97 per evitare questo, ma gli utilizzatori di Git ne soffriranno di più
  98 perché ogni clone contiene normalmente la storia completa.
  99
 100 Bisogna cercare la ragione per cui questi cambiamenti sono così grandi.
 101 Magari bisogna cambiare il formato dei file. Modifiche minori dovrebbero
 102 causare solo cambiamenti minori in solo pochi file.
 103
 104 Magari un database o un sistema d'archivio sono invece una soluzione più
 105 adatta invece di un sistema di controllo di versione. Per esempio, un
 106 sistema di controllo di versione potrebbe non essere adatto per gestire
 107 fotografie prese periodicamente da una webcam.
 108
 109 Se i file devono essere cambiare radicalmente e se devono essere gestite
 110 in versioni, una possibilità è di usare Git in maniera centralizzata. È
 111 possibile creare cloni superficiali che contengono solo una parte minore
 112 o addirittura inesistente della storia del progetto. Naturalmente in
 113 questo caso molti strumenti di Git non saranno più a disposizione, e
 114 correzioni dovranno essere fornite sotto forma di patch. Questo va
 115 probabilmente bene, visto che non sembrerebbe doverci essere nessun
 116 motivo per mantenere la storia di file ampiamente instabili.
 117
 118 Un altro esempio è un progetto che dipende da un firmware che consiste
 119 in un enorme file binario. La storia di questo firmware non interessa
 120 agli utilizzatori, e gli aggiornamenti non sono molto compressibili, il
 121 che significa che le revisioni del firmware inflazionano inutilmente il
 122 deposito.
 123
 124 In questo caso il codice sorgente dovrebbe essere salvato in un deposito
 125 Git, mentre i file binari dovrebbero essere tenuti separatamente. Per
 126 rendere la vita più facile, si potrebbe distribuire uno script che usa
 127 Git per clonare il codice sorgente, e rsync o un Git superficiale per il
 128 firmware.
 129
 130 === Contatore globale ===
 131
 132 Alcuni sistemi di controllo di versione centralizzati mantengono un
 133 numero intero che aumenta quando un nuovo commit è accettato. Git fa
 134 riferimento ai cambiamenti tramite il loro codice hash, un metodo
 135 migliore in molte circostanze.
 136
 137 Alcune persone vorrebbero però avere accesso a questo contatore.
 138 Fortunatamente è facile scrivere uno script che fa in maniera di
 139 aumentare un contatore nel deposito Git centrale ad ogni aggiornamento,
 140 magari grazie ad una tag associata con un hash dell'ultimo commit.
 141
 142 Ogni clone potrebbe mantenere un tale contatore, ma questo sarebbe
 143 probabilmente inutile, visto che solo il contatore del deposito centrale
 144 è interessante per gli utenti.
 145
 146 === Sottocartelle vuote ===
 147
 148 Sottocartelle vuote non possono essere gestite. Create dei file
 149 segnaposto per rimediare a questo problema.
 150
 151 Queste limitazioni non sono dovute a come Git è concepito, ma piuttosto
 152 a come è correntemente implementato. Con un po' di fortuna, se
 153 abbastanza utilizzatori lo richiedono, questa funzionalità potrebbe
 154 essere implementata.
 155
 156 === Commit iniziale ===
 157
 158 In informatico tipico conta a partire da 0, invece che da 1.
 159 Sfortunatamente, rispetto ai commit, Git non aderisce a questa
 160 convenzione. Molti comandi non funzionano prima del primo commit.
 161 Inoltre alcuni casi limite devono essere gestiti in maniera specifica:
 162 ad esempio, usare 'rebase' su una branch con commit iniziale diverso.
 163
 164 Git beneficerebbe della definizione del commit numero zero: non appena
 165 un deposito è costruito, HEAD verrebbe assegnato ad una stringa
 166 consistente in 20 bytes zero. Questo commit speciale rappresenterebbe un
 167 tree vuoto, senza genitori, che sarebbe presente in tutti i depositi
 168 Git.
 169
 170 In questo modo ad esempio l'esecuzione di 'git log' informerebbe
 171 l'utente che non sono ancora stati fatti commit, invece di terminare con
 172 un 'fatal error'. Una cosa simile varrebbe per altri comandi.
 173
 174 Ogni commit iniziale sarebbe implicitamente discendente da questo commit
 175 zero.
 176
 177 Ci sarebbero tuttavia casi problematici. Se diverse branch con commit
 178 iniziali diversi fossero fusi assieme con un merge, l'uso del comando
 179 'rebase' richiederebbe un sostanziale intervento manuale.
 180
 181 === Bizzarrie dell'interfaccia ===
 182
 183 Dati due commit A e B, il significato delle espressioni "A..B" e "A...B"
 184 dipende da se il comando si attende due estremità o un intervallo.
 185 Vedete *git help diff* e *git help rev-parse*.