/de/drawbacks.txt

  1== Anhang A: Git's Mängel ==
  2
  3Ein paar Git-Probleme habe ich bisher unter den Teppich gekehrt. Einige
  4lassen sich einfach mit Skripten und 'Hooks' lösen, andere erfordern eine
  5Reorganisation oder Neudefinition des gesamten Projekt und für die wenigen
  6verbleibenden Beeinträchtigungen kannst Du nur auf eine Lösung warten. Oder
  7noch besser, anpacken und mithelfen.
  8
  9=== SHA1 Schwäche ===
 10
 11Mit der Zeit entdecken Kryptographen immer mehr Schwächen an SHA1. Schon
 12heute wäre für finanzkräftige Unternehmen es technisch machbar,
 13Hash-Kollisionen zu finden. In ein paar Jahren hat vielleicht schon ein ganz
 14normaler Heim-PC ausreichend Rechenleistung, um ein Git 'Reopsitory'
 15unbemerkt zu korrumpieren.
 16
 17Hoffentlich stellt Git auf eine bessere Hash Funktion um, bevor die
 18Forschung SHA1 komplett unnütz macht.
 19
 20=== Microsoft Windows ===
 21
 22Git unter Microsoft Windows kann frustrierend sein:
 23
 24- http://cygwin.com/[Cygwin], eine Linux ähnliche Umgebung für Windows,
 25enthält http://cygwin.com/packages/git/[eine Windows Portierung von Git].
 26
 27- http://code.google.com/p/msysgit/[Git unter MSys] ist eine Alternative,
 28die sehr wenig Laufzeitunterstützung erfordert, jedoch bedürfen einige
 29Kommandos noch einer Überarbeitung.
 30
 31=== Dateien ohne Bezug ===
 32
 33Wenn Dein Projekt sehr groß ist und viele Dateien enthält, die in keinem
 34direkten Bezug stehen, trotzdem aber häufig geändert werden, kann Git
 35nachteiliger sein als andere Systeme, weil es keine einzelnen Dateien
 36überwacht. Git überwacht immer das ganze Projekt, was normalerweise schon
 37von Vorteil ist.
 38
 39Eine Lösung ist es, Dein Projekt in kleinere Stücke aufzuteilen, von denen
 40jedes nur die in Beziehung stehenden Dateien enthält. Benutze *git
 41submodule* wenn Du trotzdem alles in einem einzigen 'Repository' halten
 42willst.
 43
 44=== Wer macht was? ===
 45
 46Einige Versionsverwaltungssysteme zwingen Dich explizit, eine Datei auf
 47irgendeine Weise für die Bearbeitung zu kennzeichnen. Obwohl es extrem
 48lästig ist, wenn es die Kommunikation mit einem zentralen Server erfordert,
 49so hat es doch zwei Vorteile:
 50
 51  1. Unterschiede sind schnell gefunden, weil nur die markierten Dateien
 52     untersucht werden müssen.
 53
 54  2. Jeder kann herausfinden wer sonst gerade an einer Datei arbeitet, indem
 55     er beim zentralen Server anfragt, wer die Datei zum Bearbeiten markiert
 56     hat.
 57
 58Mit geeigneten Skripten kannst Du das auch mit Git hinkriegen. Das erfordert
 59aber die Mitarbeit der Programmierer, denn sie müssen die Skripte auch
 60aufrufen, wenn sie eine Datei bearbeiten.
 61
 62=== Dateihistorie ===
 63
 64Da Git die Änderungen über das gesamte Projekt aufzeichnet, erfordert die
 65Rekonstruktion des Verlaufs einer einzelnen Datei mehr Aufwand als in
 66Versionsverwaltungssystemen, die einzelne Dateien überwachen.
 67
 68Die Nachteile sind üblicherweise gering und werden gern in Kauf genommen, da
 69andere Operationen dafür unglaublich effizient sind. Zum Beispiel ist `git
 70checkout` schneller als `cp -a`, und projektweite Unterschiede sind besser zu
 71komprimieren als eine Sammlung von Änderungen auf Dateibasis.
 72
 73=== Der erster Klon ===
 74
 75Einen Klon zu erstellen ist aufwendiger als in anderen
 76Versionsverwaltungssystemen, wenn ein längerer Verlauf existiert.
 77
 78Der initiale Aufwand lohnt sich aber auf längere Sicht, da die meisten
 79zukünftigen Operationen dann schnell und offline erfolgen. Trotzdem gibt es
 80Situationen, in denen es besser ist, einen oberflächlichen Klon mit der
 81`--depth` Option zu erstellen. Das geht wesentlich schneller, aber der
 82resultierende Klon hat nur eingeschränkte Funktionalität.
 83
 84=== Unbeständige Projekte ===
 85
 86Git wurde geschrieben um schnell zu sein, im Hinblick auf die Größe der
 87Änderungen. Leute machen kleine Änderungen von Version zu Version. Ein
 88einzeiliger Bugfix hier, eine neue Funktion da, verbesserte Kommentare und
 89so weiter. Aber wenn sich Deine Dateien zwischen aufeinanderfolgenden
 90Versionen gravierend ändern, dann wird zwangsläufig mit jedem 'Commit' Dein
 91Verlauf um die Größe des gesamten Projekts wachsen. 
 92
 93Es gibt nichts, was irgendein Versionsverwaltungssystem dagegen machen kann,
 94aber der Standard Git Anwender leidet mehr darunter, weil normalerweise der
 95ganze Verlauf geklont wird.
 96
 97Die Ursachen für die großen Unterschiede sollten ermittelt
 98werden. Vielleicht können Dateiformate geändert werden. Kleinere
 99Bearbeitungen sollten auch nur minimale Änderungen an so wenig Dateien wie
100möglich bewirken.
101
102Vielleicht ist eher eine Datenbank oder Sicherungs-/Archivierungslösung
103gesucht, nicht ein Versionsverwaltungssystem. Ein Versionsverwaltungssystem
104zum Beispiel ist eine ungeeignete Lösung um Fotos zu verwalten, die
105periodisch von einer Webcam gemacht werden.
106
107Wenn die Dateien sich tatsächlich konstant verändern, und sie wirklich
108versioniert werden müssen, ist es eine Möglichkeit, Git in zentralisierter
109Form zu verwenden. Jeder kann oberflächliche Klone erstellen, die nur wenig
110oder gar nichts vom Verlauf des Projekts enthalten. Natürlich sind dann
111viele Git Funktionen nicht verfügbar, und Änderungen müssen als 'Patches'
112übermittelt werden. Das funktioniert wahrscheinlich ganz gut, wenn auch
113unklar ist, warum jemand die Versionsgeschichte von wahnsinnig instabilen
114Dateien braucht.
115
116Ein anderes Beispiel ist ein Projekt, das von Firmware abhängig ist, welche
117die Form einer großen Binärdatei annimmt. Der Verlauf der Firmware
118interessiert den Anwender nicht und Änderungen lassen sich schlecht
119komprimieren, so blähen Firmwarerevisionen die Größe des 'Repository'
120unnötig auf.
121
122In diesem Fall sollte der Quellcode der Firmware in einem Git 'Repository'
123gehalten werden und die Binärdatei außerhalb des Projekts. Um das Leben zu
124vereinfachen, könnte jemand ein Skript erstellen, das Git benutzt, um den
125Quellcode zu klonen und 'rsync' oder einen oberflächlichen Klon für die
126Firmware.
127
128=== Globaler Zähler ===
129
130Verschiedene Versionsverwaltungssysteme unterhalten einen Zähler, der mit
131jedem 'Commit' erhöht wird. Git referenziert Änderungen anhand ihres
132SHA1-Hash, was in vielen Fällen besser ist.
133
134Aber einige Leute sind diesen Zähler gewöhnt. Zum Glück ist es einfach,
135Skripte zu schreiben, sodass  mit jedem Update das zentrale Git 'Repository'
136einen Zähler erhöht. Vielleicht in Form eines 'Tags', der mit dem SHA1-Hash
137des letzten 'Commit' verknüpft ist.
138
139Jeder Klon könnte einen solchen Zähler bereitstellen, aber der wäre
140vermutlich nutzlos, denn nur der Zähler des zentralen 'Repository' ist für
141alle relevant.
142
143=== Leere Unterverzeichnisse ===
144
145Leere Unterverzeichnisse können nicht überwacht werden. Erstelle eine
146Dummy-Datei, um dieses Problem zu umgehen.
147
148Die aktuelle Implementierung von Git, weniger sein Design, ist
149verantwortlich für diesen Pferdefuß. Mit etwas Glück, wenn Git's Verbreitung
150zunimmt und mehr Anwender nach dieser Funktion verlangen, wird sie
151vielleicht implementiert.
152
153=== Initialer 'Commit' ===
154
155Ein klischeehafter Computerwissenschaftler zählt von 0 statt von 1. Leider,
156bezogen auf 'Commits', hält sich Git nicht an diese Konvention. Viele
157Kommandos sind mürrisch vor dem intialen 'Commit'. Zusätzlich müssen
158verschiedene Grenzfälle speziell behandelt werden, wie der 'Rebase' eines
159'Branch' mit einem abweichenden initialen 'Commit'.
160
161Git würde davon provitieren, einen Null-'Commit' zu definieren: sofort nach
162dem Erstellen eines 'Repository' wird der 'HEAD' auf eine Zeichenfolge von
16320 Null-Bytes gesetzt. Dieser spezielle 'Commit' repräsentiert einen leeren
164'Tree', ohne Eltern, irgendwann vielleicht der Vorfahr aller Git
165'Repositories'.
166
167Würde dann zum Beispiel *git log* ausgeführt, würde der Anwender darüber
168informiert, dass noch keine 'Commits' gemacht wurden, anstelle mit einem
169fatalen Fehler zu beenden. Das gilt stellvertretend für andere
170Anweisungen.
171
172Jeder initiale 'Commit' ist dann stillschweigend ein Abkömmling dieses
173Null-'Commits'.
174
175Leider gibt es noch ein paar Problemfälle. Wenn mehrere 'Branches' mit
176unterschiedlichen initialen 'Commits' zusammengeführt und dann ein 'Rebase'
177gemacht wird, ist ein manuelles Eingreifen erforderlich.
178
179=== Eigenarten der Anwendung ===
180
181Für die 'Commits' A und B, hängt die Bedeutung der Ausdrücke "A..B" und
182"A...B" davon ab, ob eine Anweisung zwei Endpunkte erwartet oder einen
183Bereich. Siehe *git help diff* und *git help rev-parse*.