The Git Index considered harmful

written by Martin H├Ącker on

Endlich hab ich mal eine ordentliche Quelle gefunden wof├╝r der Index bei GIT gut ist.

Kurz erkl├Ąrt: Der Index ist eine Vorstufe f├╝r jeden Commit. Man comittet zuerst in den index mit git add some_file und comitted dann den index ins repository mit git commit. Es sei denn man sagt git commit some_file in dem fall wird es direkt comitted, oder man w├Ąhlt eines der anderen kommandos die irgend etwas merkw├╝rdiges mit dem index anstellen, dann wei├č man in der Regel gar nicht mehr was Sache ist.

Das hab ich nie verstanden - denn wieso noch mal eine Stufe mehr, wenn man doch sowieso lokal arbeitet und alles was man verbockt hat wieder ver├Ąndern kann bevor man es pusht?

Ah well. Es gibt offenbar drei Hauptgr├╝nde:

  1. Der Index hilft besser mit einer dirty workspace zu leben
  2. Der Index hilft noch mehr ├╝ber einen commit nachzudenken und ihn zu verfeinern bevor man ihn macht
  3. Linux Torvalds hat den Index erfunden und will ihn behalten

Zu 1. Eine Dirty Workspace ist manchmal praktisch

Die Idee ist dass es Änderungen gibt die jeder in seinem lokalen Checkout hat aber niemand einchecken will. Z.B. die debug-flags, oder der andere Pfad in einem makefile. Es ist viel komfortabler jedes mal zu sagen was man committen will, als jedes mal daran zu denken was man nicht committen will. Ganz davon abgesehen dass man irgendwan nicht daran denkt das man etwas nicht machen wollte. Been there, done that.

Dieses Problem hab ich auch ab und an. Zum Beispiel dieses komische File dass einen Build-Counter f├╝r den Build-Bot enth├Ąlt. Eigentlich sollte das gar nicht in das repository. Aber dann war es doch drinnen. Und es nervte eigentlich nur, weil jeder lokale compile es erh├Âht hat. Und wenn es dann doch mal jemand comitted hat, gab es f├╝r jeden anderen nat├╝rlich einen konflikt. Sehr nervig. Oder der Debug-Flag, den man irgendwo tief in einem Framework einschalten musste. Den will ich nat├╝rlich auch nicht in einem Release haben.

Ich finde allerdings dass der Index ├╝berhaupt keine gute L├Âsung f├╝r derartige Probleme ist. Wenn ich lokale changes habe die ich nicht committen will, dann w├╝rde ich die viel lieber als "ignore" markieren, als jedes mal alles andere zu committen.

Ein bekannter formulierte das mal so, dass er oft code hat der den Code Testet den er comittet - und dass er den nicht im Repository haben will. Diese Variante des Arguments finde ich allerdings noch schrecklicher, weil ich in jedem Fall den Testcode auch im Repository haben will. Gerade. Damit ich sp├Ąter regressionstests durchf├╝hren kann. Automatisiert nat├╝rlich. Alleine der Gedanke dass der Testcode gleich wieder weggeworfen wird... schauder

Zu 2. Erst noch mal dr├╝ber nachdenken ist eine gute Idee

Das finde ich ein wesentlich besseres Argument: Man soll sich ├╝ber einen Commit Gedanken machen bevor man ihn tut. Und damit man das tut soll man genau ausw├Ąhlen was in ihn hinein kommt.

Commendable.

Allerdings nur wenn man nicht richtig dar├╝ber nachdenkt. Denn git ist ja ein distributed VCS. Das hei├čt, alle commits sind erst einmal lokal. Und kommandos die den letzten commit einfach r├╝ckg├Ąngig machen oder noch mal neu gibt es jede menge. Sogar um mehrere History-Schritte zur├╝ck zu kommen. (Und die braucht es sowieso, denn selbst mit Index macht man immer wieder Fehler.)

Oops.

Also bleibt ├╝brig: der Index ist ein zus├Ątzlicher Abstraktionsschritt der keinen Wert hinzuf├╝gt, sondern nur kompliziertere Bedienung erzeugt.

Hm. Das hei├čt nat├╝rlich frei nach Occam, dass man den Index als ├╝berfl├╝ssiges Konzept '├╝ber die klinge springen lassen' sollte.

Zu 3. Linus hats erfunden und will es behalten

Dass scheint mir der eigentliche Grund zu sein. Wie Torvalds es selber schon gesagt hat: "I have an ego the size of a small planet". Und daher wird es den Index auch weiter geben. Auch wenn es eine schlechte Idee ist. Und die git-Benutzer werden sich damit arrangieren, da niemand die Lust hat das wirklich auszufechten.

Zumindest ist das meine Einsch├Ątzung.

Schade eigentlich.

Hier mein Vorschlag: F├╝r alle Index-Liebhaber gibt es eine Option in ihrer .gitrc mit der sie den Index und wie er heute ist aktivieren k├Ânnen. F├╝r alle anderen gibt es den vern├╝nftigen default wert, der den Index einfach wie bei allen anderen Versionskontrollsystemen versteckt. Das macht man am besten so, dass bei einem Update, die .gitrc so ver├Ąndert wird, dass alle die git updaten den index behalten und alle die git neu einrichten den index explizit aktivieren m├╝ssen. Dass sollte am wenigsten Geschrei erzeugen.

Kommentare bitte per mail an spamfaenger ├Ąt gmx.de

Update: Es gibt noch viel mehr leute die mit der Git UI probleme haben. :)