Closed jbtronics closed 5 years ago
Super, danke! Ich werde mir das in nächster Zeit etwas genauer anschauen und vor allem mal testen, dauert also sicher noch ein Weilchen ;)
Der PullRequest ist leider so groß, da noch einige externe Bibliotheken hinzugekommen sind...
Welche Bibliotheken sind das denn alles? Ich würde es bevorzugen, wenn externe Bibliotheken als Submodules eingebunden würden, da es ein paar grosse Vorteile bietet:
Übrigens basiert dein Branch nicht auf unserem ´master´, könntest du ihn vielleicht noch kurz rebasen?
Hi,
gibt es irgendeine Möglichkeit bei der verwendung von submodules nur bestimmte Dateien/Ordner zu klonen? Denn sonst hätte man das Problem, dass man z.B. bei Bootstrap ( https://github.com/twbs/bootstrap ), riesige Ordnerstrukturen mit Quellcodes/Test etc. mit in die Filestruktur von Part-DB packt, wobei man eigentlich nur zwei Dateien aus dem Repo bräuchte. (Das ist bei beinahe allen Libraries so).
Oh tatsächlich, die effektiv benötigten Dateien sind nur ein winzig kleiner Teil des ganzen Repos... Bei meinen C/C++ Projekten wo ich bisher mit Submodules gearbeitet habe war es umgekehrt, da wurden jeweils sehr viele Sourcefiles benötigt, der "Overhead" war dann (relativ gesehen) eher gering ;)
Nur einzelne Dateien oder Ordner als Submodule einzubinden ist (leider?) nicht möglich. Aber dann lassen wir das einfach so wie es ist ;)
Manuelle Modifikationen an den eingebundenen Bibliotheken hast du ja nicht vorgenommen, oder? Weil das wäre etwas was nur schwer nachvollziehbar ist, und ein späteres Updaten auf eine neuere Version mühsam machen kann (insbesondere wenn es dann jemand anderes macht).
Gut Git ist vermutlich auch im Hinblick auf C/C++ entwickelt worden xD
Ja, die Bibliotheken sind alle Original, ich habe keine Veränderungen vorgenommen. Von daher sollte das kein großes Problem darstellen.
Soll ich die Commits eigentlich noch mal rebasen oder geht es auch mit einem Merge? Weil Github scheint ja zu melden, dass es keine Konflikte gibt...
Soll ich die Commits eigentlich noch mal rebasen oder geht es auch mit einem Merge? Weil Github scheint ja zu melden, dass es keine Konflikte gibt...
Ich persönlich würde es begrüssen, wenn du die Commits nochmal rebasen könntest (auch wenn keine Konflikte vorhanden sind), da so einfach der Log viel übersichtlicher bleibt. Aber ist jetzt nicht soo wichtig...
Nun ist mir aber noch aufgefallen, dass du eine .gitattributes
hinzugefügt hast, welche autocrlf
aktiviert. Bzw. ist mir zuerst aufgefallen, dass Git plötzlich rumzickt und git status
lokale Änderungen anzeigt wo keine sein sollten, erst danach sah ich dass die .gitattributes
der Grund dafür ist.
Meiner Erfahrung nach ist autocrlf
das mit Abstand nervigste (und mMn. dümmste) Feature von Git, es führt einfach immer wieder zu unglaublich mühsamen Problemen. Das einzige, das sich bei mir bisher bewährt hat, ist das komplette Deaktivieren dieses Features per * -text
in der .gitattributes
. Nur so funktioniert es sowohl unter Windows, als auch unter Linux einwandfrei.
Was meinst du dazu, hast du vielleicht andere Erfahrungen gemacht?
Ah und übrigens, auch das submodule models
macht irgendwie ein bisschen Probleme, da scheint beim entsprechenden Commit etwas schief gegangen zu sein, da das Hinzufügen einer .gitmodules
fehlt?!
Auch auf GitHub wird dieses submodule etwas komisch dargestellt, ich schätze mal weil eben eine .gitmodules
fehlt...
Wie hast du das überhaupt hingekriegt, dass das submodule trotz fehlender .gitmodules
in einem Commit aufgenommen wurde? :wink:
Hi, ok dann werde ich es die Tage mal rebasen und ich werde mal das deaktivieren von autocrlf ausprobieren. Und der models/ folder sollte eigentlich kein submodule werden... Dies erklärt aber das etwas merkwürdige Verhalten ;) Eigentlich liegt da nur ein getrenntes Git Repo drinnen, ich habe keine Ahnung wie es so ein (kaputtes) Submodule werden konnte... Sollten wir die 3D-Modelle als Submodul einbinden oder lieber tatsächlich separieren, weil vermutlich wird das nicht jeder benötigen und die Dateien sind ziemlich groß...
Ok, ich hab mal wie empfohlen die .gitattributes geändert. Nur das mit dem Rebase funktioniert nicht so wirklich: Alle paar commits entstehen, Konflikte die er nicht automatisch lösen kann, größtenteil sogar in Dateien die ich erst deutlich nach den zu rebasenden commits angelegt habe...
Also ich habe diesen Branch mal in unser repo "kopiert": smarty
Nun werde ich nach und nach einzelne Features davon in separate Branches auslagern, neue Pull Requests eröffnen, und die entsprechenden Commits aus dem smarty
Branch entfernen.
Ok, das dürfte die beste Methode sein, dass wieder alles sauber aufzutrennen. Sorry dafür, aber irgendwie hab ich das beim programmieren komplett verdrängt das man das auftrennen kann...
Als Alternative zu submodules würde sich noch anbieten, die externen Bibliotheken mit composer zu verwalten. Dann bräuchte man die gar nicht im Git zu haben.
Hi,
ja composer wäre ganz gut, ich hatte sogar etwas damit herumgespielt, hab es aber nicht weiter fortgeführt. Wie ich das verstanden habe, müsste man nach der Installation aber zuerst ein Composer command ausführen, damit er die benötigten Libs lädt, oder?
Wenn man das git auscheckt, dann ja. In Release-ZIPs könnte man die benutzten Bibliotheken weiterhin einfach mit reinpacken. Dann ändert sich für normale Benutzer nichts.
Wie hier (https://www.mikrocontroller.net/topic/305023) besprochen, habe ich meinen Code auf ein paar branches aufgeteilt. In dem Pull-Request enthalten ist die Fähigkeit Smarty als Template engine nutzen zu können, das neue Design basierend auf Bootstrap, die Übersetzungen, 3D-Modelle als Footprints und BBCode unterstützung für Kommentar und Beschreibungsfeld, desweiteren einige kleinere Anpassungen, die notwendig waren (z.B. Unterdrückung von Warnungen über überschriebene Funktionssignaturen unter PHP7). Leider war es nicht möglich die Funktionen auf weiter Branches aufzuspalten, da ich die obigen Funktionen nahezu gleichzeitig entwickelt habe und daher alles recht verwoben ist... (Ich hoffe das ist OK, falls gewünscht kann ich nochmal versuchen es etwas zu unterteilen...) Ich denke alle Funktionen sollten funktionieren, es wäre aber ganz gut wenn noch mal jemand anderes drüber schaut :) Der PullRequest ist leider so groß, da noch einige externe Bibliotheken hinzugekommen sind...
Falls ihr Fragen, Anmerkungen habt meldet euch.
Gruß Jan B.