2009-04-23 6 views
1

Ich versuche zu verstehen, wie Git besser funktioniert.Wie entscheidet GIT, was in einen Blob geht?

Gibt es einige willkürliche Dateien und eine beliebige Anzahl von Commits, wie entscheidet sich git, wie diese Dateien in Blobs aufgeteilt werden, die dann eindeutig mit SHA-1-Hashes identifiziert werden?

Ich habe gerade etwa 10 Commits von Perl/C/Java-Code und Text in neue Git Repo und irgendwie Git unterteilt die Dateien in kleine Segmente, wie hat es entschieden, wie diese Segmente geteilt werden sollten?

Antwort

7

Git erstellt einen Blob für den Inhalt jeder Datei, es sei denn, derselbe Inhalt existiert bereits (in diesem Fall wird der Blob wiederverwendet). Aber es gibt noch mehr - git erstellt auch Objekte für jedes Verzeichnis, Commit und signierte Tag. Jedes Objekt wird in .git/objects gespeichert, bis das Repository neu gepackt wird (automatisch oder durch Ausführen von git gc). In diesem Fall werden einige der Objekte zusammengefügt und in eine Packdatei deligiert (in .git/objects/pack).

Es teilt nicht den Inhalt einer einzelnen Datei zwischen mehreren Blobs oder kleinen Segmenten, wie Sie scheinen zu denken.

+0

OK, danke für den ersten Teil, hilft viel, auf den letzten Punkt, ich denke, was mich verwirrt, ist, dass das Durchsuchen einer bestimmten Datei mit GiTK File Viewer Git scheint zu wissen, was bestimmte zu tun Teile einer neu kombinierten Datei kamen von, dort habe ich die "Segmente", wie bestimmt Git die Bestimmung und woher diese Segmente kamen und woher weiß man, dass zum Beispiel eine oft wiederholte Zeile wie "make" Teil von unique ist Segment und nicht eine wiederholte Änderung in eigener Sache? –

+0

Ich bin mir nicht sicher, was du meinst. Wenn Sie die Unterschiede, die es im Vergleich zur letzten Revision zeigt, meinen, nennt man das "Diff" und wird im Handumdrehen berechnet, indem Sie die beiden Dateien vergleichen. Wenn Sie die Schuldanzeige in git gui meinen, die durch einen cleveren Schuldzuweisungsalgorithmus erfolgt, sehen Sie in der Befehlszeile "git tschuldigung". Es funktioniert in etwa wie ein Diff, wird aber für jede Revision erstellt und berücksichtigt auch entfernte Zeilen aus anderen Dateien. – Pieter

+0

OK, danke, ich glaube, ich verstehe jetzt, was mich verwirrt von anderen untergeordneten SCMs (SVN/CVS/perforce) war, dass sie normalerweise nicht automatisch gegen ältere Revisionen diffundieren konnten, die in anders benannten Dateien in verschiedenen Verzeichnissen existierten, außer Verzweigungen wurde explizit gemacht, was ich in diesem Fall nicht mit Git gemacht hatte. Also, ich verstehe jetzt, dass das 2 separate Probleme sind, wie das "clevere" diff/blame algo funktioniert und wie Code in Blobs gespeichert wird. Ich markiere deine als die Antwort, fühle mich frei, Details hinzuzufügen, wenn uns etwas anderes in den Sinn kommt Git Neulinge ... Danke –

1

Alle Dateien gehen in einen Blob, aber das bedeutet nicht notwendigerweise, dass Git eine Datei pro Blob speichert (Git hat ein hoch effizientes gepacktes Format, das Dinge zusammenfügt). Wenn Sie sich für die Interna bezüglich des Packformats von Git interessieren, fragen Sie besser auf ihrer Liste nach oder lesen Sie ihre Architekturdokumentation.

+0

OK, ich habe die Dokumente gelesen, aber ich versuche, den Lernprozess für mich und die nächste Person auf SO zu beschleunigen, ich konnte diese Frage bisher nicht durch Lesen von Dokumenten beantworten. Guter Rat zum Fragen auf der Liste, ich werde das tun, wenn nichts hier oben kommt. –

+0

Dies ist das Beste, was ich finden konnte, http://eagain.net/articles/git-for-computer-scientists/, aber es beantwortet nicht wirklich die Frage. –

+0

Die Mailingliste ist wirklich die einzige Ressource, die Sie für diese spezielle Frage verwenden sollten. (Oder Sie könnten den Quellcode lesen) – Arafangion

3

Ich schlage vor, Sie einige der grundlegenden (das heißt "Low-Level") Referenzen zu überprüfen. Für Ihre spezielle Frage, sehen Sie sich den Abschnitt Git Object Model im Git Community Book an.

Danach könnten Sie interessiert sein zu lesen Git from the Bottom Up (PDF) oder die ausgezeichnete Git Internals (PDF, US$9) für ein Verständnis der Low-Level-Under-Pinnings von Git (das "Content-adressierbare Dateisystem" und gerichtete azyklische Grafik Beziehungen).

Verwandte Themen