write section on index

Makefile

@@ -124,6 +124,6 @@ docker: .docker
 	touch .docker
 
 with-docker: | docker
-	docker run -v ${PWD}:/build:rw -it $${DOCKER_TAG:-itt:latest} "make -C /build $(RULE)"
+	docker run -v ${PWD}:/build:rw $${DOCKER_TAG:-itt:latest} "make -C /build $(RULE)"
 
 .PHONY: paper presentation mindmap clean docker polish

paper/paper.md

@@ -317,39 +317,51 @@ Daher wird auch kein Neues Objekt für Dateien beziehungsweise Verzeichnisse
 angelegt, die sich nicht verändert haben.
 Auch wenn zwei Dateien beziehungsweise Verzeichnisse den selben Inhalt haben,
 muss nur ein Satz Objekte gespeichert werden.
-Weiterhin ändert sich am blob Objekt einer Datei beim Umbennen nichts,
+Weiterhin ändert sich am blob Objekt einer Datei beim Umbenennen nichts,
 nur das tree Objekt wird modifiziert.
 Dieses Konzept wird als *Deduplizierung* bezeichnet.
 
 Dies Bedeutet aber auch das falls sich nur ein sehr kleiner Teil einer großen
 Datei ändert,
 werden zwei nahezu identische Objekte mit unterschiedlichem Hash angelegt.
-Dies erfordert somit überproportinal viel Speicher,
+Dies erfordert somit überproportional viel Speicher,
 weswegen der Objektspeicher mittels *Deltakompression* komprimiert wird.
 
 Der Hash eines tree Objektes wird auch über die Hashes der enthaltenen
-tree und blob Objekete gebildet.
-Und der Hash jedes Commit Objektes wird unteranderem über die Hashes
+tree und blob Objkete gebildet.
+Und der Hash jedes Commit Objektes wird unter anderem über die Hashes
 des tree Objektes und der Vorgänger Commits gebildet.
 Somit ergibt sich eine Kette kryptographischer Hashes, wodurch die *Integrität*
 des Projektverzeichnisses und der gesamten Versionsgeschichte sicherstellt wird.
 
 Dadurch das ein Commmit mehrere Vorgänger hat lässt sich die Versionsgeschichte
-als gerichter Graph ohne Zyklen (*DAG*) betrachten.
+als gerichteter Graph ohne Zyklen (*DAG*) betrachten.
 In Abbildung \ref{fig:graph} ist ein solcher abgebildet.
-Ein Zyklus ist theortisch nicht ausgeschlossen,
-aber nur erschopfende Suche möglich, da wenn sich zwei Commits gegenseitig als
+Ein Zyklus ist theoretisch nicht ausgeschlossen,
+aber nur erschöpfende Suche möglich, da wenn sich zwei Commits gegenseitig als
 Vorgänger haben sollen, für den jeweiligen Hash der jeweils andere
 Hash bereits bekannt sein müsste.
 Die Knoten, wie in Abbildung \ref{fig:graph} zu sehen, entsprechen den Commits
 und die Vorgänger Beziehung ist durch die Kanten ausgedrückt.
-Zweige entsprechen in diesem Modell zeigern auf Commits.
-Das verständniss vieler Operationen wird durch dieses Modell vereinfacht.
+Zweige entsprechen in diesem Modell Zeigern auf Commits.
+Das Verständnis vieler Operationen wird durch dieses Modell vereinfacht.
 
 ![Exemplarischer Versionsgraph](../grafiken/example-graph.pdf){#fig:graph}
 
-
-## TODO: Index und Commits
+Eine Besonderheit von Git ist der Index, oder auch *Staging Area*, genannt,
+der als Schnittstelle zwischen Arbeitsverzeichnis und Repository fungiert.
+Änderungen aus dem Arbeitsverzeichnis werden zünachst mittels der Add
+Operation im Index gesammelt und mittels der Commit Operation
+in das Repository übernommen.
+Der Index enthält für jede Datei eine Referenz auf ein Objekt,
+dieses kann ein anderes sein als das der entsprechenden Datei im
+Arbeitsverzeichnis oder Repository.
+Mittels einer Add Operation werden Änderungen aus dem Arbeitsverzeichnis
+in den Index übernommen und benötigte Objekte erstellt.
+Mit der Reset Operation können Inhalte aus dem Repository in den Index
+und optional in das Arbeitsverzeichnis übernommen werden.
+Somit lässt sich die nächste Version inkrementell erstellen
+und muss nicht dem Zustand des Arbeitsverzeichnisses entsprechen.
 
 ## TODO: Branching und Tags