Tortoise Git, Dateien und Icons

DocShoe

Hallo zusammen!

Problem:
Wir arbeiten mit dem Embarcadero RAD Studio und stellen alle Dateien einer Bibliothek unter Versionskontroller, inklusive der Projektdateien (*.cbproj, enthält alle Quelltextdateien und Einstellungen), damit man die Bibliothek nach einem clone direkt bauen kann. Leider aktualisiert das RAD Studio ständig die Projektdatei, sei's nur, um einen Zeitstempel zu aktualisieren. Das führt natürlich dazu, dass es aus git-Sicht eine Änderung ist und TortoiseGit das Overlay-Icon für eine geänderte Datei benutzt (und rekursiv die Ordner aufwärts, in denen sich diese Datei befindet). Damit entsteht der Eindruck, dass sich am Quelltext irgendwas geändert hätte, obwohl nur in der Projektdatei ein Zeitstempel geändert wurde.

Kann man TortoiseGit irgendwie beibringen, für bestimmte Dateien, die zwar unter Versionskontrolle stehen, den Status nicht auszuwerten?

SeppJ

Ich weiß nicht, ob tortoise-git da irgendwie anders ist (das ist nur ein Frontend, oder?), aber: Es gibt in git die Möglichkeit, beliebige Programme auf die Dateien anzuwenden, bevor sie durch den stage/commit-Prozess gehen. Siehe smudge- und clean-Filter hier:
https://git-scm.com/book/ms/v2/Customizing-Git-Git-Attributes
(oder an vielen anderen Stellen zu den Stichworten smudge und clean)

Wenn du da einen clean-Filter einbaust, der den Zeitstempel auf einen Standardwert setzt (und beim smudge zurück auf die aktuelle Zeit? Oder den Standardwert belassen? Musst du überlegen), dann sind Änderungen am Zeitstempel für git quasi unsichtbar, denn es sieht nur das, was du durch den Filter lässt.

Ich muss aber warnen, dass ich da schlechte Erfahrungen in verteilten Projekten damit habe. Denn das ist eine lokale Filterung, keine Eigenschaft des Repositories allgemein. Wenn du die Zeitstempel rausfilterst, aber jemand anderes an dem Projekt ohne diese Filter arbeitet, dann kommt alles total durcheinander. Dann sieht dein git, dass da Änderungen an den Dateien in den fremden Commits sind, aber die gleichzeitig sind die Änderungen für git unsichtbar, weil alle Dateien noch bei dir durch den Filter gehen, und viel Spaß dabei, so eine Situation zu korrigieren.

hustbaer

Ich würde ein Ticket bei ~~RAD Studio~~ Embarcadero aufmachen.
Ist ja völlig unbrauchbar wenn das Ding das Projektfile die ganze Zeit unnötig ändert.

DocShoe

@SeppJ
Es geht nur um die Projektdatei, da ist das Verhalten vom RAD Studio einfach bescheiden. Da steht der Zeitstempel des Speicherzeitpunktes als Text in der Projekttdatei. Die Aktion Projekt öffnen, Projekt schließen aktualisiert den Inhalt der Projektdatei, obwohl nichts gemacht worden ist. Das ist im Zusammenspiel mit git halt sehr nervig.
Ich würde jetzt aber keinen eigenen Handler bauen, der den Zeitstempel in der Datei der Zeitstempel (ja auf welchen Wert denn genau?) zurücksetzt, so weh tut das jetzt doch nicht.

@hustbaer
Ich kann da mal ein Ticket aufmachen, aber ich glaube, das interessiert da niemanden.

hustbaer

@DocShoe sagte in Tortoise Git, Dateien und Icons:

@hustbaer
Ich kann da mal ein Ticket aufmachen, aber ich glaube, das interessiert da niemanden.

Ich hab' mit denen keine Erfahrung. Aber ich würd's auf jedem Fall versuchen.

Ist halt schon ziemlich nervig wenn man die Projekt-Files in Source-Control hat, egal welches System man verwendet (Git, SVN, ...) -- und Projekt-Files in Source-Control zu verwalten ist ja nun nicht gerade was ausgefallenes.

SeppJ

Ich habe mal ein bisschen rumgegoogelt und wenigstens bist du nicht der einzige mit dem Problem. Aber die Lösung ist quasi was ich vorgeschlagen habe, nur ein bisschen ausgekügelter (weil da anscheinend auch die Reihenfolge der Einstellungen sortiert werden muss - zumindest 2017, als das geschrieben wurde). Was soll man auch sonst machen? Entweder muss das, wie hustbaer sagt, vom Hersteller gemacht werden, oder man muss eben selber passend machen, was nicht passt.

https://www.uweraabe.de/Blog/2017/01/18/dproj-changed-or-not-changed/
https://www.uweraabe.de/Blog/2017/01/24/dprojnormalizer-for-xe7-and-xe8/

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

https://www.uweraabe.de/Blog/2017/01/18/dproj-changed-or-not-changed/

Man muss sich schon ernsthaft fragen, ob die Entwickler überhaupt mit ihrer eigenen Software arbeiten oder was die für einen Workflow haben, wenn dieses (IMHO massive) Problem anscheinend fast 8 Jahre dort niemanden gestört hat. Meines Erachtens gehören "Projektdateien" wie Makefiles, CMake-Skripte oder eben diese .cbproj-Dateien selbstverständlich ebenfalls unter Versionsverwaltung.

Apropos CMake: RAD Studio scheint das ja irgendwie auch zu unterstützen, ich weiß aber nicht wie gut. Vielleicht ist das ja eine Option, mit der man die .cbproj-Dateien irgendwie umgehen könnte. Allerdings wäre es auch ein ziemlicher Akt, ein größeres Projekt auf CMake umzustellen, daher ist das wahrscheinlich nicht praktikabel und der "Djprojnormalizer" vermutlich die bessere Lösung. Ich persönlich versuche allerdings immer, die IDE-spezifischen Projektdateien zu vermeiden und das alles soweit möglich mit CMake zu machen. Hat den Vorteil besserer Portabilität, da man sich nicht an einen Compiler und eine IDE bindet.

SeppJ

@Finnegan sagte in Tortoise Git, Dateien und Icons:

@SeppJ sagte in Tortoise Git, Dateien und Icons:

https://www.uweraabe.de/Blog/2017/01/18/dproj-changed-or-not-changed/

Man muss sich schon ernsthaft fragen, ob die Entwickler überhaupt mit ihrer eigenen Software arbeiten oder was die für einen Workflow haben, wenn dieses (IMHO massive) Problem anscheinend fast 8 Jahre dort niemanden gestört hat. Meines Erachtens gehören "Projektdateien" wie Makefiles, CMake-Skripte oder eben diese .cbproj-Dateien selbstverständlich ebenfalls unter Versionsverwaltung.

RAD Studio ist alt, und Borland (die ursprünglichen Entwickler) noch viel älter. Da ist git mit seinen 20 Jahren geradezu ein neuer Hype im Vergleich. Ich kann mir gut vorstellen, dass man bei Borland immer wieder mal die Frage gestellt hat "Sollen wir nicht auf git umsteigen?", und die Antwort war jedes Mal, dass ihre bisherigen Versionsverwaltungsmethoden gut genug sind, die Migration (oder gar Verlust!) der Historie zu schwer wiegen würde, die Toolchains und Workflows seit Jahrzehnten etabliert sind, und daher die Vorteile eines Umstiegs einfach zu gering. Und alle paar Jahre wurde das vielleicht wieder hinterfragt, aber dann war das Projekt und seine Historie noch größer, die Toolchain und Workflows noch länger etabliert, etc.

Auch wenn sie langsam aussterben, gibt es daher immer noch genug Nutzer von alternativen Versionsverwaltungssystemen, die das Problem vielleicht anders handhaben. Ich kann natürlich nur raten bezüglich Borland/Embarcadero, aber solche Geschichten gibt es doch zuhauf. Ich habe bei mir auf der Arbeit selber mal versucht, die befreundete nicht-Programmierer-Abteilung zu ihrem Glück mit git zu überzeugen, aber deren SVN-Repo war sowas von entartet (Gigabyteweise Binaries ) und so alt, dass eine Konvertierung Stunden dauerte, und danach war die Akzeptanz einfach nicht da, weil man nicht umlernen wollte vom schönen klickibunti Tortoise-SVN auf git, und das niemand genutzt hat. Soweit ich weiß, nutzen die das immer noch...

DocShoe

@SeppJ

Das Eine hat nichts mit dem Anderen zu tun. Man kann gleichzeitig ein altes Versionskontrollsystem benutzen und gleichzeitig dafür sorgen, dass die Projektdateien aufgeräumt bleiben. Man hat das Projektdateiformat (ist ne Art Xml) einige Male erweitert, zB, um Android und MacOS zu unterstützen. Da hätte man auch gleichzeitig die Sortierung von Einträgen usw. sicherstellen können. Und den Zeitstempel nicht schreiben, die kriegt man auch über den Zeitstempel der Datei raus.

Edit:
Danke für die Hinweise, aber ich glaube, ich möchte keine 6 Jahre alte Hobbylösung ausprobieren. Kann gut sein, dass sie funktioniert, und mit dem nächsten RAD Studio Update zerschießt sie die Projektdateien, das möchte ich nicht riskieren.

hustbaer

Der Zeitstempel wäre nichtmal ein Problem, wenn er nur aktualisiert würde sofern man auch wirklich Änderungen im Projekt gemacht hat.
Dass die Einträge ihre Reihenfolge ändern ist aber natürlich immer ein Problem.
Beides sollte aber leicht zu fixen sein.

hustbaer

p.S.: so nen "Normalizer" könnte man sich wohl auch selbst schreiben, ist denke ich auch nicht SO das grosse Problem.

Angenommen...

Das File ist standardkonformes XML
Man liest das File ohne Schema Validation in ein generisches DOM ein
Man macht in dem DOM nur Änderungen von denen man weiss dass sie "sicher" sind, wie bestimmte Elemente zu sortieren und den Zeitstempel auszutauschen

...dann sollte das mMn. auch halbwegs sicher/zuverlässig sein. Wenn Änderungen gebraucht werden, kann man sie dann selbst machen. Und falls wirklich mal was daneben geht, verliert man auch maximal die letzte Änderung -- die, die man committen wollte zu dem Zeitpunkt wo der Normalizer das File zerschossen hat.

SeppJ

An sich ist das fein und aus der git-Nutzersicht schön unsichtbar, aber wie ich oben schon sagte, kommt man in Teufels Küche, wenn man da irgendwie verteilt dran arbeitet und jemand (z.B. ein neuer Mitarbeiter) das nicht weiß (und man vergisst es zu erwähnen, weil es so unsichtbar ist), und da eine "verseuchte" Datei comitted. Die dann auch noch schön auf alle Kopien gepullt wird, bevor man es merkt, am besten noch dass jemand von so einem verseuchten Zustand wegbrancht und seine Branch-Historie nicht verlieren will.

Man kann das alles beheben, sogar sauber, aber man muss wirklich verstehen, wie das mit den Filtern, dem git-Arbeitsverzeichnis, dem Staging Area, usw. funktioniert. Wenn du dir vorstellen kannst, das so eine Situation eintreten kann (wenn du alleine dran arbeitest, sollte das kein Problem sein), dann würde ich unbedingt vorher ein paar Ernstfälle simulieren, diese in aller Ruhe zufriedenstellend beheben, und aufschreiben was man zu tun hat, um alle Mitarbeiter wieder auf einen sauberen Stand zu bringen.

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

An sich ist das fein und aus der git-Nutzersicht schön unsichtbar, aber wie ich oben schon sagte, kommt man in Teufels Küche, wenn man da irgendwie verteilt dran arbeitet und jemand (z.B. ein neuer Mitarbeiter) das nicht weiß (und man vergisst es zu erwähnen, weil es so unsichtbar ist), und da eine "verseuchte" Datei comitted. Die dann auch noch schön auf alle Kopien gepullt wird, bevor man es merkt, am besten noch dass jemand von so einem verseuchten Zustand wegbrancht und seine Branch-Historie nicht verlieren will.

Es gibt da so ne Git-Option für Konvertierung zwischen Unix- und Windows-Zeilenenden (CRLF). Da hatte ich es auch mal mit einer widersprüchlichen Konfiguration zu tun, was dann dazu führte, dass stets alle Dateien als verändert erkannt wurden. Zum Glück ist das vor dem Commit aufgefallen und es gab auch nur eine handvoll Entwickler. Das ist auch so ein Ding, mit dem man sich schnell die Historie zerschießen kann, wenn man nicht aufpasst. Commits, bei denen für 10.000 Dateien jede Zeile im Diff auftaucht, sind leider nur bedingt hilfreich, wenn man Änderungen nachvollziehen will

(CRLF ist echt auch so ein nerviges Ding, mit dem man ein Leben lang Spaß haben kann: Meiner Erfahrung nach sollte man im Zweifel immer Unix-LF bevorzugen. Ich kenne zumindest keine Windows-Tools und Editoren, die damit nicht klarkommen, während sich Builds mit Unix-Fokus (autotools et al.) immer mal wieder an sowas verschlucken. Oft mit sehr seltsamen Symptomen, bei denen man lange nach der Ursache suchen kann).

Finnegan

@SeppJ sagte in Tortoise Git, Dateien und Icons:

RAD Studio ist alt, und Borland (die ursprünglichen Entwickler) noch viel älter.

Ich fühl mich auch schon ganz schön alt, wenn ich bedenke, das Borland ziemlich heißer Scheiß war, als ich meine ersten Programmier-Schritte mit Turbo Pascal und Turbo C++ gemacht habe

Das Phänomen kann man oft bei Software mit so einer langen Geschichte beobachten (kürzlich mit einer Autodesk-Software gearbeitet, die stellenweise auch Duft diverser jahrzehntealter Verkrustungen versprüht). Zum Teil ist sowas wegen der alten Codebase verständlich, aber ich denke daran sind auch Entwickler nicht ganz unschuldig, die sich einer gewissen Altersbequemlichkeit ergeben haben, und sich nur ungern mit neuen Dingen befassen. Erinnert mich ein wenig an meinen alten Herrn, der Musik der 1980er noch immer für "modernes Zeug der Jugend von heute" hält, während die tatsächlich schon lange zur "Musik der Großväter" geworden ist

Ich finde auch, dass man nicht jeden aktuellen Hype hinterherrennen sollte (da wird schon oft jede Menge Schwachsinn durchs Dorf getrieben), aber bei Dingen, die sich rational als sinnvoll erweisen, sollte man schon ein bisschen mit der Zeit gehen.

wob

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Commits, bei denen für 10.000 Dateien jede Zeile im Diff auftaucht, sind leider nur bedingt hilfreich, wenn man Änderungen nachvollziehen will

Naja, du kannst den Commit-Hash ja in die .git-blame-ignore-revs schreiben. Sowas haben wir z.B. gemacht, wenn wir den Code-Formatter gewechselt haben und einen reinen Formatierungscommit hatten.

Und wenn der Commit nur versehentlich drin war UND du eine kleine Anzahl Entwickler hast, kannst du auch "einfach" den Commit wieder aus dem Repo löschen. Nicht dass ich ein großer Fan davon wäre, aber in diesem Fall kann das tatsächlich sinnvoll sein. Und dann überlegen, warum es kein Review gab bzw. warum das im Review nicht aufgefallen ist.

Nutzt ihr z.B. pre-commit? Da würde man doch normalerweise sowas checken können.

*john 0

@Finnegan sagte in Tortoise Git, Dateien und Icons:

@SeppJ sagte in Tortoise Git, Dateien und Icons:

RAD Studio ist alt, und Borland (die ursprünglichen Entwickler) noch viel älter.

Ich fühl mich auch schon ganz schön alt, wenn ich bedenke, das Borland ziemlich heißer Scheiß war, als ich meine ersten Programmier-Schritte mit Turbo Pascal und Turbo C++ gemacht habe

Ich entsinne mich daran, dass Pascal der heißeste Scheiß für Kleincomputer war (z.B. Language Card für Apple II), und in Folge Turbo Pascal entstand. Ich hatte zwar nie einen Apple II, kann mich aber noch sehr gut an die Kästen erinnern. Und daran, dass damals Watcom der C bzw. C++ unter DOS das Werkzeug der Wahl war. Nun ja, da ich später vor allem auf UNIX programmieren gelernt habe, nutzt ich seit Ewigkeiten den GCC, der in seinen Anfängen ähnlich prähistorisch wie Turbo Pascal ist.

Mir scheint, dass Borland nie so richtig den Wechsel von DOS auf Windows hinbekommen hat, und mit dem Bedeutungsverlust, der mit diesem Wechsel einher ging, niemals zurecht kam. Der Versuch auf Linux wirklich Fuß zu fassen, hat auch nicht so richtig geklappt. Danach habe ich das Produkt ehrlich gesagt aus den Augen verloren.

Das Phänomen kann man oft bei Software mit so einer langen Geschichte beobachten (kürzlich mit einer Autodesk-Software gearbeitet, die stellenweise auch Duft diverser jahrzehntealter Verkrustungen versprüht).

Ganz ehrlich GCC ist deutlich besser gealtert als Borlands/Embarcaderos Produkte.

Finnegan

@wob sagte in Tortoise Git, Dateien und Icons:

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Commits, bei denen für 10.000 Dateien jede Zeile im Diff auftaucht, sind leider nur bedingt hilfreich, wenn man Änderungen nachvollziehen will

Naja, du kannst den Commit-Hash ja in die .git-blame-ignore-revs schreiben. Sowas haben wir z.B. gemacht, wenn wir den Code-Formatter gewechselt haben und einen reinen Formatierungscommit hatten.

Und wenn der Commit nur versehentlich drin war UND du eine kleine Anzahl Entwickler hast, kannst du auch "einfach" den Commit wieder aus dem Repo löschen. Nicht dass ich ein großer Fan davon wäre, aber in diesem Fall kann das tatsächlich sinnvoll sein. Und dann überlegen, warum es kein Review gab bzw. warum das im Review nicht aufgefallen ist.

Nutzt ihr z.B. pre-commit? Da würde man doch normalerweise sowas checken können.

Nein, es hat ja nicht mal ein Commit stattgefunden. Das war nur ein Beispiel wie schnell sowas passieren kann, wenn man nicht aufpasst. core.autocrlf = true war zumindest damals noch ne Default-Einstellung von Git für Windows. Das wird eher dann zum Problem, wenn man Neulinge im Team hat, die sich z.B. nicht wundern, weshalb so viele Dateien bei den Änderungen aufgelistet sind.

Finnegan

@john-0 sagte in Tortoise Git, Dateien und Icons:

Ganz ehrlich GCC ist deutlich besser gealtert als Borlands/Embarcaderos Produkte.

Zu letzteren kann ich nicht viel sagen, aber GCC ist allerdings nur ein Compiler ohne IDE und Windows-Support hatte GCC selbst auch nie wirklich (das kam vom MinGW-Projekt). Aber sie haben die Kurve dennoch durchaus gut hinbekommen und dabei eine ganze Reihe alter unterstützter Architekturen erhalten. Im Quellcode sehe ich da immer noch Support für z.B. den M68k. Wäre mal ne Probe wert, wie gut sich Amiga-Programme in C++23 schreiben lassen. Ein Test vor Jahren mit einer entsprechend zusammengestellten Toolchain hat allerdings gemessen an z.B. der originalen A500-Hardware ganz schön große Executables erzeugt (Hallo Welt). Die C++-Standardbibliothek ist denke ich nicht unbedingt für sowas ausgelegt - vor allem iostreams.

Bei einem aktuellen (Retro-) Hobbyprojekt von mir habe ich ein ähnliches Problem. Da baue ich mit GCC 14 DOS-Programme (MZ-Executables) mit dem Original i386 ohne FPU als Zielarchitektur. Mit C-Code kommt "Hallo Welt" da auf wenige KiB. Und das, obwohl da noch eine malloc-Implementierung und Teile der libc mit drin stecken. Mit C++ gehts kaum unter 200 KiB - hauptsächlich für Exception Handling für das der Compiler trotz -fno-exceptions/-fno-rtti immer noch jede Menge Code emittiert. Sobald ich das "Hallo Welt" mit cout mache, explodiert die Executable dann auf etwa 1.3 MiB. Dass man nicht für das bezahlt, was man nicht nutzt, scheint jedenfalls nicht immer zu stimmen - theoretisch sollte man ja meinen, dass sich das je nach Implementierung zu einem simplen write(stdout, "Hallo, Welt!", 12); optimieren lassen müsste. Da landet aber wohl doch noch nen Haufen ungenutztes Zeug mit in der EXE.

Damn, jetzt schweif ich aber ganz schön ab. Genug OT

SeppJ

Ja, ist ganz schön schlecht, wenn die Zielplattform nicht dynamisch linken kann. Da bleibt die ja eigentlich nur, die Standardbibliothek raus zu werfen, und eine enorm abgespeckte C++-DOS-Library für einfaches IO zu suchen. Oder selber schreiben? DOS hat ja nur ein paar Handvoll Syscalls. Und damit sollte dann ja die volle Macht von C++ als Sprache verfügbar sein. Das wird ein Spaß, wenn all die komischen Ausnahmen, die Sprachpuristen immer anmeckern (z.B. ob man Pointer vergleichen darf, die sich nicht auf das gleiche Array beziehen), auf einmal super-wichtig werden.

*john 0

@Finnegan sagte in Tortoise Git, Dateien und Icons:

Zu letzteren kann ich nicht viel sagen, aber GCC ist allerdings nur ein Compiler ohne IDE und Windows-Support hatte GCC selbst auch nie wirklich (das kam vom MinGW-Projekt). Aber sie haben die Kurve dennoch durchaus gut hinbekommen und dabei eine ganze Reihe alter unterstützter Architekturen erhalten. Im Quellcode sehe ich da immer noch Support für z.B. den M68k. Wäre mal ne Probe wert, wie gut sich Amiga-Programme in C++23 schreiben lassen.

Wenn man eine Turbokarte oder eine Vampire (die gibt es mittlerweile mit 1GB RAM) mit halbwegs ausreichend RAM hat, könnte das gelingen. Mein alter Amiga müsste ich erstmal wieder betriebsfähig machen, wahrscheinlich sind die Elkos hinüber.

Ein Test vor Jahren mit einer entsprechend zusammengestellten Toolchain hat allerdings gemessen an z.B. der originalen A500-Hardware ganz schön große Executables erzeugt (Hallo Welt). Die C++-Standardbibliothek ist denke ich nicht unbedingt für sowas ausgelegt - vor allem iostreams.

Ich hatte mit dem cc65 Compiler für 6502 Plattformen herumgespielt "Hello World!" für C128 2,7kB und das war nur C89. Wenn man da an den VIC20 denkt. Der Emulator kann natürlich wunderbar viel RAM zur Verfügung stellen, weil

Dass man nicht für das bezahlt, was man nicht nutzt, scheint jedenfalls nicht immer zu stimmen - theoretisch sollte man ja meinen, dass sich das je nach Implementierung zu einem simplen write(stdout, "Hallo, Welt!", 12); optimieren lassen müsste.

Optimierende Linker scheinen nicht wirklich in Gebrauch zu sein. Templates, so toll sie auch sind, sind leider richtig übel was den Speicherverbrauch fürs Executable betrifft. Es gab da mal ein Versuch im GCC (RTO oder wie hieß das nochmal?) das zu optimieren, was aber in endlos langen Compile Orgien endete.