Commit 473bfb55 authored by Lukas Nagel's avatar Lukas Nagel
Browse files

write section on index

parent a5041b07
......@@ -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
......@@ -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
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment