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 :stupid:

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:

Zitat von Delbor (Beitrag 1377052)

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:

Zitat von Rollo62 (Beitrag 1377054)

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.

[Sherlock]

Die DFM werden in meinem Berlin auch ständig geändert...

Sherlock

[jaenicke]

Zitat:

Zitat von Glados (Beitrag 1377184)

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.

Wenn man das automatische Speichern der Projektdatei aktiviert hat, wird aber das Formular nicht mehr automatisch beim Öffnen des Projekts geöffnet. Solange man also nicht wirklich dieses Formular aufruft, passiert dies dann nicht.

Die Explicit Werte und Imagelisten werden ja bei Formularen auch ohne diesen zusätzlichen Bug modifiziert. Deshalb macht das ohnehin Sinn.

[Der schöne Günther]

Ich verbringe jeden Tag mehrere Minuten damit ungewollte Änderungen (hauptsächlich DFM und DPROJ) rückgängig zu machen bzw. die Änderungen explizit abzuwählen. Daran muss man sich wohl gewöhnen 8-)

[himitsu]

Ein paar der Änderungen bekommt man z.B. mit dem IDE-Fix-Pack weg, direkt beim Speichern.

Im Prinzip müsste man solche Ändernungen auch beim DFM-Diff rausfiltern lassen können.
Für XML gibt es doch auch sowas.

[Glados]

Und wenn man dann einmal solch eine Änderung explizit macht? :P

[himitsu]

Das macht man nicht. :stupid:

Wenn sowas nur beim Vergleich gefilter wird, dann wird es beim nächsten Einchecken alles mit hochgeladen.
Nur beim Vergleich, würde es heißen "keine Änderung", wenn sonst nichts Anderes geändert wurde.

Der IDE-Fix-Pack schmeißt nur solche Property raus, die sonst kein Mensch verwendet.
Aber nee, ExplicitWidth war in den DDevExtensions und nicht im IDE-Fix-Pack.
https://stackoverflow.com/questions/...g-in-dfm-files
http://andy.jgknet.de/blog/ide-tools/ide-fix-pack/

Und nur weil man z.B. eine Datei-Endung auf ignore gesetzt hat, heißt es nicht, dass man soeine Datei nicht dennoch explizit aufnehmen kann. Diese Datei wird nur "standardmäßig" nicht als unversioniert aufgeliestet.