Verständnisfrage zu Tortoisegit

[Delbor]

Hi zusammen

Wie arbeitet Git? Ich habe ein neues Repository auf meiner neueen externen Platte angelegt, dieses anschlieesend in mein Arbeitsverzeichnis (auf einer internen Partition) geclont und schliesslich das Arbeitsverzeichnis markiert und einen Comit auf das oben erwähnte Repository durchgeführt und nach einer Kontrolle der beteilgten Unterverzeichnisse und Dateien gepusht.
Dabei habe ich mich nach diesem Tutorial gerichtet.
Wie da beschrieben, erhielt ich eine erfolgreiche Rückmeldung, und als ich das Logeinsah, wurden mir alle beteiligten Dateien angezeigt.

Nur - das Repository, in das ich commitet hatte, enthält nach wie vor keine meiner Projekt-Dateien...

Was macht Tortoisegit, bzw. Git damit?

Die jpegs im Anhang zeigen das Log und das von mir angelegte Repository.

Gruss
Delbor

[Aviator]

Deine committeten Daten liegen verschlüsselt in den Unterordnern des Unterordners Objects des Git Repositories.

Deine eigentlichen Source Dateien werden ja eine Ebene über den ".git" Ordner gespeichert. Die Daten sind also schon vorhanden. Allerdings in einem Zustand, mit dem Du ohne GIT nichts mehr anfangen kannst.

[Delbor]

Hi Aviator

Danke für Deine Antwort! Dieser Unterordner 'objects' ist nach wie vor wenige kb gross. Das bedeutet, das der hauptsächlich ein Zeiger auf die eigentlichen Daten ist.
Andrerseits - ich hab das Repository gerade mal angelegt, aber noch keine Änderungen am Original vorgenommen. Und wenn nun Git gerademal die Änderungen im Repository speichert, ist da noch nichts, das gespeichert werden müsste.
Was für mich zum jetzigen Zeitpunkt ziemlich spannend ist: Git speichert vieles auf C:\. Ich kann nur hoffen, dass die Versionsgeschichten nicht physisch da landen, sondern in den Repositorys, die von mir angelegt wurden, bleiben. Mein C:\ ist nicht beliebig gross...

Gruss
Delbor

[Rollo62]

Was ich von Zeit zu Zeit mal mache ist, ich clone das Projekt in ein neues Verzeichnis,
und synchronisiere diese zum Vergleich (ohne die .git Verzeichnisse natürlich).
Man ist ja Paranoid

Du kannst natürlich über .gitignore Files steuern was überhaupt gespeichert werden soll und was nicht.

Bisher war das immer 1:1 OK, also wird es GIT sauber speichern.
Es ist schon ziemlich eingeschrumpft, mit der Historie, also da mache ich mir mittlerweile keine Sorgen mehr.

Rollo

[Delbor]

Hi Rollo

Zitat:

Du kannst natürlich über .gitignore Files steuern was überhaupt gespeichert werden soll und was nicht.

Das hab ich erstmal nicht gemacht. Git hat mir, mit Ausnahme des*.dprj.local alle Dateien commited, auch die .Hystorie von Delphi, obwohl das auf SVN beruht - ich finde das aber fürs erste gar nicht schlecht.

Gruss
Delbor

[Rollo62]

Das bläht aber den GIT-Commit unnötig auf.
Ich weiss auch nicht ob diese History auch funktioniert wenn du auf einem 2ten Rechner arbeitest.
Ich mache vor jedem Commit noch ein Clean per Batch-Datei, damit diese "Leichen" nicht aus Versehen mitgesichert werden.

Rollo

[jaenicke]

Zitat von Delbor:

Das hab ich erstmal nicht gemacht. Git hat mir, mit Ausnahme des*.dprj.local alle Dateien commited, auch die .Hystorie von Delphi, obwohl das auf SVN beruht - ich finde das aber fürs erste gar nicht schlecht.

Also bei mir habe ich da Häkchen, mit denen ich beim Hinzufügen und Committen prüfe was ich haben will und was nicht.

Blind alles reinwerfen macht nicht viel Sinn. Denn dann weißt du ja gar nicht was wirklich zu dem Beschreibungstext gehört, den du angegeben hast und was nur "zufällig" mit drin ist.

Du kannst dir ja mal meine kleine History anschauen als Beispiel:
https://github.com/jaenicke/MTCL/commits/master/source

[CCRDude]

Ich könnte mir vorstellen, dass Du auf der externen Platte ein "bare" Repository angelegt hast. Dann ist dort nicht der aktuelle Stand einsehbar, sondern das komplette Repository ist nur in der Verwaltungsstruktur. Das passt auch zum ".git" als Endung des Pfadnamens.

Wechsle doch mal in ein Terminal, dort in das Verzeichnis auf der externen Platte, und gebe dort

Code:

git rev-list --objects --all

ein. Dann siehst Du alle Dateien, die darin gespeichert sind.

Ein bare repo ist eben nicht dafür da, um drin zu arbeiten, also spart es sich die direkten Dateien und beinhaltet sie nur in seinen Datenbanken.

[Phoenix]

Zitat von Rollo62:

Das bläht aber den GIT-Commit unnötig auf.
Ich weiss auch nicht ob diese History auch funktioniert wenn du auf einem 2ten Rechner arbeitest.
Ich mache vor jedem Commit noch ein Clean per Batch-Datei, damit diese "Leichen" nicht aus Versehen mitgesichert werden.

Uh. Für sowas gibt es eigentlich das .gitignore file.
Für Delphi gibt's da diese Vorlage hier: https://github.com/github/gitignore/...lphi.gitignore

Wenn diese .gitignore Datei in Deinem Repo liegt (am besten als erstes committen), dann wird Git den Historie-Folder sowie alles was nicht ins Repo gehört automatisch ignorieren.
Da braucht man keine Batchfiles zum Aufräumen laufen lassen

[Glados]

Zitat:

Du kannst natürlich über .gitignore Files steuern was überhaupt gespeichert werden soll und was nicht.

Ich verwende dafür diesen Helfer:

Zitat:

# Created by https://www.gitignore.io/api/delphi

### Delphi ###
# Uncomment these types if you want even more clean repository. But be careful.
# It can make harm to an existing project source. Read explanations below.
#
# Resource files are binaries containing manifest, project icon and version info.
# They can not be viewed as text or compared by diff-tools. Consider replacing them with .rc files.
#*.res
#
# Type library file (binary). In old Delphi versions it should be stored.
# Since Delphi 2009 it is produced from .ridl file and can safely be ignored.
#*.tlb
#
# Diagram Portfolio file. Used by the diagram editor up to Delphi 7.
# Uncomment this if you are not using diagrams or use newer Delphi version.
#*.ddp
#
# Visual LiveBindings file. Added in Delphi XE2.
# Uncomment this if you are not using LiveBindings Designer.
#*.vlb
#
# Deployment Manager configuration file for your project. Added in Delphi XE2.
# Uncomment this if it is not mobile development and you do not use remote debug feature.
#*.deployproj
#
# C++ object files produced when C/C++ Output file generation is configured.
# Uncomment this if you are not using external objects (zlib library for example).
#*.obj
#

# Delphi compiler-generated binaries (safe to delete)
*.exe
*.dll
*.bpl
*.bpi
*.dcp
*.so
*.apk
*.drc
*.map
*.dres
*.rsm
*.tds
*.dcu
*.lib
*.a
*.o
*.ocx

# Delphi autogenerated files (duplicated info)
*.cfg
*.hpp
*Resource.rc

# Delphi local files (user-specific info)
*.local
*.identcache
*.projdata
*.tvsconfig
*.dsk

# Delphi history and backups
__history/
__recovery/
*.~*

# Castalia statistics file (since XE7 Castalia is distributed with Delphi)
*.stat

# End of https://www.gitignore.io/api/delphi

Durch einen aktuellen Bug in 10.2, der das Hauptformular einfach in der Höhe ändert ohne den Nutzer zu fragen (ist schließlich ein Bug),
hat man in quasi jedem Commit noch DFM-Dateien drin die man eigentlich gar nicht geändert hat.

Bei C++ ist das wesentlich einfacher und sauberer. Bei Delphi muss man je nach Projekt seine eigene gitignore-Regeln erstellen.